Graphic library and GUI

Forum thread started by Hiei on Mon, 2005-06-20 18:46

Hi all!

I'm wondering if should be possibile to port on Haiku the "Enlightenment Fountation Libraries (EFL)", and then use them as a base framework for the actual and an eventual new GUI (for the second and next releases). This library could be wrapped on standard BeOS API and next them could be improved to support all the thing EFL provide.

http://www.enlightenment.org/Libraries/Overview.html

I'm not asking to port Enlightenment Window Manager, that's not! But watch at what these libraries can do! They created a very very fast window manager and it's very looking fine! I think this could be the right way for Haiku too. We could create a very fast and usable GUI as the original one, but with a good style that could help beos from looking just "old" to newbies. And it also could help writing good and fast applications.

Bye
Hiei

Comments

Re: Graphic library and GUI

Hiei wrote:
Hi all!

I'm wondering if should be possibile to port on Haiku the "Enlightenment Fountation Libraries (EFL)", and then use them as a base framework for the actual and an eventual new GUI (for the second and next releases). This library could be wrapped on standard BeOS API and next them could be improved to support all the thing EFL provide.

http://www.enlightenment.org/Libraries/Overview.html

I'm not asking to port Enlightenment Window Manager, that's not! But watch at what these libraries can do! They created a very very fast window manager and it's very looking fine! I think this could be the right way for Haiku too. We could create a very fast and usable GUI as the original one, but with a good style that could help beos from looking just "old" to newbies. And it also could help writing good and fast applications.

Bye
Hiei

Just think of what you've said there. How could using a WRAPPED library make the GUI any faster? It'd only be wrapping the same GUI libs as are already there...

Graphic library and GUI

When I say WRAP I just say to "modify" the API interface, from C to C++. The lost in performance is very low. It isn't the same from wrapping these libraries from C to Python or from C to Java. These libraries has been created exactly to be used as low level API for a GUI, to be "Fast, light and performing libraries", and I think they are what haiku needs, not for first release, but if it want's to become a competitive alternative to windows, osx and linux, it needs a good look & feel without loose responsivity and speed.

Graphic library and GUI

But Haiku's graphical API already using a backend - AGG - to do low level drawing. And based on my experience of Enlightenment, its going to be far faster than anything Rasterman wrote..

Also, are you suggesting the Be API is C there, or that the Enlightenment libs are C? Because the Be API is most certainly C++....

Graphic library and GUI

Yes, AGG is a nice library for R1, and will provide such features as fully antialiased drawing throughout the entire OS.

The major change of rendering backend I can see happening is a switch to a hardware-accelerated OpenGL one, that I imagine would be written from scratch. Could be wrong though.

Graphic library and GUI

I know BeOS API are written in C++, and also that actually AGG is used for Haiku R1. But AGG doesn't appear to be a library designed for GUI, its first three features, from the web site, are:

# Anti-Aliasing.
# Subpixel Accuracy.
# The highest possible quality.

And I don't think that a desktop needs subpixel accuracy, and highest quality... It also doesn't provide any hardware acceleration. EFL could use an OpenGL backend, and as tb100 said, it could be useful for Haiku R2.

I don't know what you think about Rasterman, but I've been impressed from actual alpha version of E17!

Graphic library and GUI

Hiei wrote:
I know BeOS API are written in C++, and also that actually AGG is used for Haiku R1. But AGG doesn't appear to be a library designed for GUI, its first three features, from the web site, are:

# Anti-Aliasing.
# Subpixel Accuracy.
# The highest possible quality.

And I don't think that a desktop needs subpixel accuracy, and highest quality... It also doesn't provide any hardware acceleration.

R1 will have the same amount of 2D hardware acceleration as R5 - screen to screen blits and so on. I think subpixel and quality settings of AGG can be controlled - so for most drawing of the OS, it will be set up for speed rather than quality.

Graphic library and GUI

Ok, my initial question was primary for curiosity... But anyway I think that could be useful to code the graphic subsistem considering the evolution it could take in R2. We'll see in the future what will be the right choice. Anyway, I can't wait anymore for Haiku to be ready!!! :wink:

Re: Graphic library and GUI

ahoj! ako sa mas? this is my first post. i have seen how both haiku and enlightenment 17 are reaching maturity around the same time. i was curious if porting e17 to haiku would be amazing or what! so i googled it and found this thread. I know this thread is old as religion, but it asks some interesting questions. does anyone think that the decision here not to use EFL for haiku might not be correct anymore due to progress or changes in the two projects in the past 5+ years? I'm familiar with a tiny bit of programming, and quite familiar with operating systems, so it seems like it might be a good idea to me but I am not sure what problems might arise from the programming aspect of it. Personally, I love haiku, but it needs beautified some, it looks ancient. e17 and the EFL have some pretty nice features that have the same ideas as haiku about being lightweight yet powerful. what about just changing the gui code for the backend of the beos window manager? like I said, I'm not clear on the technical details, so I'm asking for anyones thoughts on the topic. cau

Re: Graphic library and GUI

A modern, fully-accelerated display mechanism, would be wonderful, but it would be a shame if it compromised Haiku's existing visual language and crisp aesthetics. The current design seems to convey an understated but playful elegance that invites user exploration. Simplicity and minimalism are timeless, perhaps.

Re: Graphic library and GUI

bzyzny wrote:

ahoj! ako sa mas? this is my first post. i have seen how both haiku and enlightenment 17 are reaching maturity around the same time. i was curious if porting e17 to haiku would be amazing or what! so i googled it and found this thread. I know this thread is old as religion, but it asks some interesting questions. does anyone think that the decision here not to use EFL for haiku might not be correct anymore due to progress or changes in the two projects in the past 5+ years? I'm familiar with a tiny bit of programming, and quite familiar with operating systems, so it seems like it might be a good idea to me but I am not sure what problems might arise from the programming aspect of it. Personally, I love haiku, but it needs beautified some, it looks ancient. e17 and the EFL have some pretty nice features that have the same ideas as haiku about being lightweight yet powerful. what about just changing the gui code for the backend of the beos window manager? like I said, I'm not clear on the technical details, so I'm asking for anyones thoughts on the topic. cau

So add those EFL features, but don't bloat the system for needless eye candy. its always better to extend the API vrs changing it like underwear or boxers.

Linux hasn't gotten to beta 1 yet, despite claims to the contrary.

Re: Graphic library and GUI

I'm not sure why someone was suddenly compelled to necro this thread, but...

thatguy wrote:

Linux hasn't gotten to beta 1 yet, despite claims to the contrary.

Linux 1.0 is almost seventeen years old.

A "beta" is the feature complete test phase. It certainly is remarkable that after nearly a decade Haiku still isn't feature complete even judged against the rather low bar set for it at the start of OpenBeOS. But Be were never much better, later releases were all shipped by feature trimming, ie you set a deadline and you just rip stuff out until you hit that deadline. This means there's quite a contrast between the optimism of previews and the reality for anyone who bought it.

Re: Graphic library and GUI

NoHaikuForMe wrote:

I'm not sure why someone was suddenly compelled to necro this thread, but...

thatguy wrote:

Linux hasn't gotten to beta 1 yet, despite claims to the contrary.

Linux 1.0 is almost seventeen years old.

A "beta" is the feature complete test phase. It certainly is remarkable that after nearly a decade Haiku still isn't feature complete even judged against the rather low bar set for it at the start of OpenBeOS. But Be were never much better, later releases were all shipped by feature trimming, ie you set a deadline and you just rip stuff out until you hit that deadline. This means there's quite a contrast between the optimism of previews and the reality for anyone who bought it.

Linux is a kernel. As far as kernels go I don't really agree with the statement that its not a beta. To actually achive beta you'd first have to stop breaking the abi and api on every release. Having a undefined set of broken and halfass implemented features is not a good thing.

exactly what features is haiku missing ?

Re: Graphic library and GUI

thatguy wrote:

Linux is a kernel. As far as kernels go I don't really agree with the statement that its not a beta. To actually achive beta you'd first have to stop breaking the abi and api on every release. Having a undefined set of broken and halfass implemented features is not a good thing.

You seem to be confusing the userspace API and ABI, which Linux preserves, and the internal kernel API and ABIs which are changed as necessary. Changes to the internal API and ABIs only matter if you are in fact a Linux kernel developer, in which case it's part of your role to keep track, or if you develop out-of-tree drivers, which is frowned upon.

Both the userspace and kernel ABI evolve, but in different ways. The userspace ABI evolves only by growing, the introduction of the race-free openat(2) didn't get rid of open(2) so programs which use open(2) will continue to function indefinitely. But the kernel ABI both adds and removes things. For example, back in the 1990s when Linux was made SMP a Big Kernel Lock was added, drivers had to be updated to use the BKL or they did not function correctly on multi-processor machines. Now the BKL is being removed, it is optional in new releases, so new drivers should use a more fine-grained lock (or create one) instead. But nothing changed for userspace applications by this process.

Quote:

exactly what features is haiku missing ?

In real terms the list is huge, but sticking just to OpenBeOS as conceived it really comes down to just two, application compatibility with BeOS (still some BeOS programs won't work for one or another reason) and hardware compatibility which means Haiku itself doesn't work for some people.

Re: Graphic library and GUI

NoHaikuForMe wrote:

You seem to be confusing the userspace API and ABI, which Linux preserves, and the internal kernel API and ABIs which are changed as necessary. Changes to the internal API and ABIs only matter if you are in fact a Linux kernel developer, in which case it's part of your role to keep track, or if you develop out-of-tree drivers, which is frowned upon .

Thanx for proving my point. The driver function problem alone is madening enough.

NoHaikuForMe wrote:

Both the userspace and kernel ABI evolve, but in different ways. The userspace ABI evolves only by growing, the introduction of the race-free openat(2) didn't get rid of open(2) so programs which use open(2) will continue to function indefinitely. But the kernel ABI both adds and removes things. For example, back in the 1990s when Linux was made SMP a Big Kernel Lock was added, drivers had to be updated to use the BKL or they did not function correctly on multi-processor machines. Now the BKL is being removed, it is optional in new releases, so new drivers should use a more fine-grained lock (or create one) instead. But nothing changed for userspace applications by this process..

Oh hoseshit, they still break the usespace ABI and API all the time, Which is why very few commercial third party apps get developed. Companies don't want to chase a moving target and have to constantly rebuild there apps every kernel release.

NoHaikuForMe wrote:

In real terms the list is huge, but sticking just to OpenBeOS as conceived it really comes down to just two, application compatibility with BeOS (still some BeOS programs won't work for one or another reason) and hardware compatibility which means Haiku itself doesn't work for some people.

In your terms the list is huge. In the communitys terms the list is small. Aot of the features you claim haiku is missing are features that simply aren't needed by desktop users to begin with. Did it occur to you that Haiku users don't want a linux like OS in most ways.

I can agree on 2 features one of which is simply a bug hunt.

Re: Graphic library and GUI

thatguy wrote:

Thanx for proving my point. The driver function problem alone is madening enough.

Really? You don't seem too bothered about it in Haiku.

Quote:

Oh hoseshit, they still break the usespace ABI and API all the time

Concrete examples please, of how the Linux kernel "breaks" its userspace ABI and API "all the time". Any?

Quote:

, Which is why very few commercial third party apps get developed. Companies don't want to chase a moving target and have to constantly rebuild there apps every kernel release.

Commercial apps like Skype, you mean? Which I installed on a laptop for someone last year, and, despite several kernel upgrades, the same exact version of Skype is running just fine? Or games like World of Goo? Maybe Oracle? Or something like Frame Thrower?

Quote:

In your terms the list is huge. In the communitys terms the list is small. Aot of the features you claim haiku is missing are features that simply aren't needed by desktop users to begin with. Did it occur to you that Haiku users don't want a linux like OS in most ways.

Here's five randomly chosen features, which of these "simply aren't needed by desktop users" and why is this claim any different from saying they should stick with MS DOS 5.0 ?

• Colour Management
• Hotplug SATA / eSATA drives
• Network file sharing
• Hardware 3D acceleration
• Firewire soundcards

Re: Graphic library and GUI

NoHaikuForMe wrote:

Really? You don't seem too bothered about it in Haiku.

Concrete examples please, of how the Linux kernel "breaks" its userspace ABI and API "all the time". Any?

Commercial apps like Skype, you mean? Which I installed on a laptop for someone last year, and, despite several kernel upgrades, the same exact version of Skype is running just fine? Or games like World of Goo? Maybe Oracle? Or something like Frame Thrower?

Here's five randomly chosen features, which of these "simply aren't needed by desktop users" and why is this claim any different from saying they should stick with MS DOS 5.0 ?

• Colour Management
• Hotplug SATA / eSATA drives
• Network file sharing
• Hardware 3D acceleration
• Firewire soundcards

I am tired of multi qouting you its getting pretty god damned annoying and frankly your pretty annoying.

In this order.

Driver support in haiku at this point of the project should be expected to be poor. Only becuase thats the LASt thing the Os team should be working on before APPs. I will say that on average the standard haiku drivers that work, are more useful then the linux counterparts.

You need concrete examples ? Wow your fanboism reeks. go look at the damn bug tickets on a kernel update.

Wow, how that photoshop support ? Microsoft office " even apple has MS office "

what apps again ? Oh thats right, server software or shitty toy apps. Got it.

To adress your 5 random short falls " which are debatable.

1. color management.

this is a hack of colosal proportions. Its like applying compression on audio to try and correct a source volume issue.
Try finding and using the Menu button on your monitor and buy a test pattern from a AV store. If the input is wrong, color correcting it for display will only screw it up at the time of printing.

If the printer needs color correction, its defective.

2. Hot pluging of sata/Esata drives.

yep lots of non server people hot plugging drives all the time. In fact its one of my favorite pass times. Take the drive out and put it back in. Hmmm I think this is a red herring for 90% of computer users.

3. network file sharing.

Yeah so whats your point. Its a single user system. Its not a server OS. If you want a server OS maybe you should stick with linux. There is a semi functional Samba port that could likely be brought up to full operation quickly when r1 gets closer.

4. Hardware 3d acceleration.

Yes this would be nice. But unless you do 3d gaming " which users statistics indicate 70% of PC users don't. Its a moot point. but its not like anyone but windows has gaming covered. Last I checked they were the only OS with modern 3d gamming. don't even decry linux having 3d gamming. Its a joke and the same games are already ported or are being ported to haiku. There is work on the gallium3d driver stack port to, but its been dormant for sometime.

I would argue mode setting capability is far more pertinent.

5. firewire sound cards.

Yeah lots of firewire audio devices, mostly studio based.sound like a real concenr with the whole 1% of the PC market being used for audio recording on multichannel firewire devices. Most of which are being phased out for usb 2.0 and now usb 3 and then theres the overwhelming fact that the maudio and other pci cards are vastly more popular and better quality.

so to redress, Haiku doesn't meet your needs, which is fine. Since it doesn't meet your needs maybe you should troll on back to a linux website where you guys can all sit around and egostistically masturbate each other on your bash skills and file sharing prowess with your uber broken distrobution scheme multiple window managers and non interoperable Os landscape.

Enjoy your self and don't hurt that shoulder patting yourselves on the back. Its only taken 20 years for Linux to still not be a prominent desktop OS.

Re: Graphic library and GUI

thatguy wrote:

You need concrete examples ? Wow your fanboism reeks. go look at the damn bug tickets on a kernel update.

Yes, concrete examples, not an ad hominem attack. This would only be difficult if you didn't have any, in which case your assertion that this happens "all the time" would be entirely unjustified.

ABI compatibility is a big issue for Haiku, so it's certainly worth having an opinion. But it is most helpful if the opinion is informed by the facts.

Re: Graphic library and GUI

NoHaikuForMe wrote:
thatguy wrote:

You need concrete examples ? Wow your fanboism reeks. go look at the damn bug tickets on a kernel update.

Yes, concrete examples, not an ad hominem attack. This would only be difficult if you didn't have any, in which case your assertion that this happens "all the time" would be entirely unjustified.

ABI compatibility is a big issue for Haiku, so it's certainly worth having an opinion. But it is most helpful if the opinion is informed by the facts.

Are you seriously trying to actually wage a argument the the linux kernel is api and abi stable ? Are you fucking high ?

Like I said. If you want proof, just start pulling bug tickets about kernel upgrade breakages. Its about that simply. There are a few thousand in the system.

Haiku has a ABI issue ? sometimes it might. But then it doesn't claim to be stable or ready for release now does it.

you should stick to linux. you'll be happy over there with your big gaint buggy kernel.

Re: Graphic library and GUI

thatguy wrote:

Are you seriously trying to actually wage a argument the the linux kernel is api and abi stable ? Are you fucking high ?

The Linux kernel does a great job of maintaining userspace API and ABI compatibility, as I explained. This has been somewhat important to its success.

Quote:

Like I said. If you want proof, just start pulling bug tickets about kernel upgrade breakages. Its about that simply. There are a few thousand in the system.

Concrete examples are what I asked for, not vague references to "thousands" of bug reports.

Re: Graphic library and GUI

NoHaikuForMe wrote:

The Linux kernel does a great job of maintaining userspace API and ABI compatibility, as I explained. This has been somewhat important to its success.

Concrete examples are what I asked for, not vague references to "thousands" of bug reports.

Linux has no abi api issues at the kernel level ? Wow. It doesn't get broken intentionally, it gets broken becuase change one item might break 10 more items.

Linux is a sucess, double wow. 1% desktop market penetration. Thats sucess with a capital fail. Just to add

Linux is only free if your time is worthless.

If only either of your statements were true.

you could go find the proof you seek, but then the truth is uglier then you can admit.

Re: Graphic library and GUI

thatguy wrote:

Linux has no abi api issues at the kernel level ? Wow. It doesn't get broken intentionally, it gets broken becuase change one item might break 10 more items.

I think you need to review this part of the thread again.

Quote:

Linux is a sucess, double wow. 1% desktop market penetration. Thats sucess with a capital fail.

Yes, Linux is a huge success, I'm not sure why you have trouble understanding that. Millions of desktop users although impressive in its own right is just a tiny corner of the big picture. By the way although success does not have a "capital fail" it does have two letter Cs in it.

Re: Graphic library and GUI

NoHaikuForMe wrote:

I think you need to review this part of the thread again.

Yes, Linux is a huge success, I'm not sure why you have trouble understanding that. Millions of desktop users although impressive in its own right is just a tiny corner of the big picture. By the way although success does not have a "capital fail" it does have two letter Cs in it.

Linux is a sucess for companies that don't want to pay microsoft liscensing fees by the core. whats really ammusing is that Most companies install Linux, then VM software and then run theres apps in virtualization. It is usually do to the lisencsing of the core/cpu count and nothing to do with and supposed superiority of the OS.

super computers need a highly configurable and very flexiable OS. They use the linux kernel becuase its EASY. If these project had the time to write a new kernel, they likely would.

Linux is not a sucess on phones, Its just cheap. But thats going to change with Microsoft marching in. I bet MS will give windows phone 7 away if they can keep the money makers, apps/games.

You obviously don't understand bussiness.

there nothing linux does that someone else doesn't already do or most likely do it better.

My reason for choosing haiku has to do with my need not being met by any of the other players out there.

Re: Graphic library and GUI

I have quickly looked over the posts between thatguy & NoHaiku.

Please guys cool it. Understand that every person chooses the OS that is best for them. So, bashing each other's OSes does not help.

People should use what works for them and makes them happy.
If you like Haiku. Use it. If you like Linux. Use it.

I realize that everyone feels strongly about their favorite OS but let's stay calm & non-combative. Thanks.

Re: Graphic library and GUI

tonestone57 wrote:

I have quickly looked over the posts between thatguy & NoHaiku.

Please guys cool it. Understand that every person chooses the OS that is best for them. So, bashing each other's OSes does not help.

People should use what works for them and makes them happy.
If you like Haiku. Use it. If you like Linux. Use it.

I realize that everyone feels strongly about their favorite OS but let's stay calm & non-combative. Thanks.

You gotta admit, the pictures were funny.

Re: Graphic library and GUI

tonestone57 wrote:

Please guys cool it. Understand that every person chooses the OS that is best for them. So, bashing each other's OSes does not help.

In my experience if you want civility (or indeed anything else in particular) on a forum you need clear rules and someone to enforce them. That's how Elitist Jerks is able to function for example. My understanding is that Haiku lacks the manpower to do that. So realistically you're not only going to have "bashing" but you are also going to get ad hominems, irrelevant posts, thread necromancy, and so on.

Persuading thatguy of his errors is an unlikely outcome, my intention is to avoid the situation (very common on BeOS forums, and now on this Haiku forum) where mistaken claims about the OS are allowed to mislead bystanders. Almost ten years after BeOS ceased development there are still people who claim BFS is actually able to store files up to 2^64 bytes long, because they read that somewhere and nobody corrected it. Such myths cause problems, whether they're about BeOS, Haiku, or Windows 95.

Re: Graphic library and GUI

NoHaikuForMe wrote:
tonestone57 wrote:

Please guys cool it. Understand that every person chooses the OS that is best for them. So, bashing each other's OSes does not help.

In my experience if you want civility (or indeed anything else in particular) on a forum you need clear rules and someone to enforce them. That's how Elitist Jerks is able to function for example. My understanding is that Haiku lacks the manpower to do that. So realistically you're not only going to have "bashing" but you are also going to get ad hominems, irrelevant posts, thread necromancy, and so on.

Persuading thatguy of his errors is an unlikely outcome, my intention is to avoid the situation (very common on BeOS forums, and now on this Haiku forum) where mistaken claims about the OS are allowed to mislead bystanders. Almost ten years after BeOS ceased development there are still people who claim BFS is actually able to store files up to 2^64 bytes long, because they read that somewhere and nobody corrected it. Such myths cause problems, whether they're about BeOS, Haiku, or Windows 95.

Mostly your just a troll. There no puersuading needed. I have no problem telling you to can it. We don't need a linux troll. Everybody has one and no one can stand them.

We don't need your corrections, we'd all be better off if you just stayed logged out.

http://en.wikipedia.org/wiki/Troll_(Internet)