Linked by Thom Holwerda on Sat 26th May 2007 20:18 UTC, submitted by GhePeU
Gnome The GNOME Community Roadmap is a big-picture view of functionality we expect GNOME to include in short-term and long-term future. The roadmap is based on feedback from current GNOME developers and other community members. This roadmap shows the ideas and hopes of GNOME contributors for the near future.
Thread beginning with comment 243339
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE: nice work
by thebluesgnr on Sat 26th May 2007 23:10 UTC in reply to "nice work"
thebluesgnr
Member since:
2005-11-14

'why does that even have to be written?'.

That's how software works.

Why does evince need 'editable toolbar', wouldn't that come as default in each app?

I also wonder why it needs editable toolbars, since the default is so nicely designed. But anyway, Gtk+ doesn't support editable toolbars yet; the code exists in libegg, and developers can simply copy and paste it to their application. This isn't exactly nice, but it's a good way to have the code mature until it's ready to be part of a stable library like GTK+.

Speaking of evince, it's nice to know KDE 4 will have a similar application. Hopefully it will share resources with evince by using libpoppler, which AFAIK KDE doesn't do yet.

and several apps seem to need to implement printing multiple pages - does each gnome dev need to waste his time on such basic infrastructure stuff?

Not really. You see, GTK+ has a new printing API (which, by the way, was developed without GNOME having to launch a new major version) and it works great, but not all features are implemented yet. The "several apps" you mentioned are actually two - Evince and Eog - and they're waiting on proper GTK+ support to land that feature.

That won't lead to consistency, I guess.

Consistency is one of GNOME's strongest features.

Anyway, let's hope they can finish all this stuff and catch up with the competition.

It's already superior to Vista's interface in my opinion, and it even beats Mac OS X in several points.

Edited 2007-05-26 23:11

Reply Parent Score: 5

RE[2]: nice work
by TSDgeos on Sat 26th May 2007 23:30 in reply to "RE: nice work"
TSDgeos Member since:
2007-05-26

Hopefully it will share resources with evince by using libpoppler


http://webcvs.freedesktop.org/poppler/poppler/ChangeLog?revision=1....

I can see some @kde.org addresses there

Reply Parent Score: 3

RE[3]: nice work
by superstoned on Sun 27th May 2007 00:12 in reply to "RE[2]: nice work"
superstoned Member since:
2005-07-07

of course, Okular dev's are working on poppler. They have since the beginning (not sure, they might even have initiated it)

Reply Parent Score: 3

RE[2]: nice work
by superstoned on Sun 27th May 2007 00:22 in reply to "RE: nice work"
superstoned Member since:
2005-07-07

'why does that even have to be written?'.

That's how software works.


shouldn't such stuff have been in the libs 5 years ago, like in KDE?

Speaking of evince, it's nice to know KDE 4 will have a similar application. Hopefully it will share resources with evince by using libpoppler, which AFAIK KDE doesn't do yet.

Albert Astals Cid is one of the main developers on both Poppler and KPDF (which will be Okular in KDE 4).

It's already superior to Vista's interface in my opinion, and it even beats Mac OS X in several points.

OK, so only KDE to catch up on. All things you just explained have been working in KDE for 5 years or more, so it's well time to finally get these things in GTK/Gnome apps. I wonder how much time it did const to have to check and change each application to abide with the Gnome HIG while KDE just wrote some libraries which lead to the same consistency (at least in the area's covered by those libs, like men & toolbars, network transparancy, shortcut handling, printing etc).

Anyway, as I said, it's a nice roadmap, some might say 'too little too late' but time will tell. I DO wonder what their answer to KDE 4 will be, of course, but it would actually be a good thing for 'the linux desktop' if it would be a good answer, so let's hope for that. All happy (well, as long as they're working on free software, as they should ;) ).

Reply Parent Score: 5

RE[2]: nice work
by segedunum on Sun 27th May 2007 01:39 in reply to "RE: nice work"
segedunum Member since:
2005-07-06

That's how software works.

Software works on layers, and you implement what is common in the layers below for the layers above to inherit.

I also wonder why it needs editable toolbars, since the default is so nicely designed. But anyway, Gtk+ doesn't support editable toolbars yet;

Editable toolbars has been on the drawing board in GTK+ for years. It's by no means new (2003):

http://www.osnews.com/story.php/5453/Interview-Red-Hats-Owen-Taylor...

"...the support for editable toolbars is there, and the GTK+-2.4 version Epiphany has editable toolbars, but GTK+-2.4 itself won't contain the user interface for editing toolbars or the support for saving the results of editing."

It doesn't paint a particularly great picture of GTK as a library, or programming in Gnome. User interface stuff like this positively and simply has to be in a universal common, well structured library in a modern desktop environment. Any third-party developer is going to be mighty confused by this, and it isn't great from a bugs point of view either. Where on Earth is the bug?

Consistency is also a major factor here from a user and usability, as well as a consistent HIG and look-and-feel, point of view. Some applications have it, some don't and it's sometimes different between applications? What's going on?

...the code exists in libegg, and developers can simply copy and paste it to their application.

I am positively and physically cringing as I read that.

...but it's a good way to have the code mature until it's ready to be part of a stable library like GTK+.

To be honest, I think that opens a can of worms. Once you copy and paste code it's out of control. The priority should be to get such functionality into a common library and inherit, or not at all. This is a modern desktop that uses a common toolkit with APIs that actually binds applications together into a desktop? I have that right, don't I?

Speaking of evince, it's nice to know KDE 4 will have a similar application.

It has for some time, in various forms.

Hopefully it will share resources with evince by using libpoppler, which AFAIK KDE doesn't do yet.

From what I've heard, Okular will use Poppler.

You see, GTK+ has a new printing API (which, by the way, was developed without GNOME having to launch a new major version)

Welcome to 1995. I'm not sure why having that put in without launching a major new version should be particularly impressive. Sounds like it should be.

Consistency is one of GNOME's strongest features.

Taking into account the above evidence, and the way things are being done, that doesn't look very true. Consistency implies commonality between applications and the desktop, and if they're not all singing from the same hymn sheet than there isn't much consistency. Telling developers to individually follow a set of guidelines doesn't really count.

It's already superior to Vista's interface in my opinion, and it even beats Mac OS X in several points.

If you have application developers, and third-party developers, having to create their own independent GUI widgets, and widgets other desktops have had for years at that, then you've got a dog's breakfast interface-wise. Vista and Mac OS X have inheritable APIs and components for doing all this since...forever.

Reply Parent Score: 5

RE[3]: nice work
by Mystilleef on Sun 27th May 2007 03:20 in reply to "RE[2]: nice work"
Mystilleef Member since:
2005-06-29

It doesn't paint a particularly great picture of GTK as a library, or programming in Gnome. User interface stuff like this positively and simply has to be in a universal common, well structured library in a modern desktop environment. Any third-party developer is going to be mighty confused by this, and it isn't great from a bugs point of view either. Where on Earth is the bug?


Editable toolbar is in a library called libegg. Most developers do not need editable toolbars. And those who do can use libegg.

To be honest, I think that opens a can of worms. Once you copy and paste code it's out of control. The priority should be to get such functionality into a common library and inherit, or not at all. This is a modern desktop that uses a common toolkit with APIs that actually binds applications together into a desktop? I have that right, don't I?


Untested and unpopular APIs should never be placed in a toolkit. APIs should added based popular request and need. And of course, after lots of testing.

Taking into account the above evidence, and the way things are being done, that doesn't look very true. Consistency implies commonality between applications and the desktop, and if they're not all singing from the same hymn sheet than there isn't much consistency. Telling developers to individually follow a set of guidelines doesn't really count.


Consistency is overrated. I don't see how the absence of editable toolbars make applications "hymn" out of sync. Have you used Windows? Do all Windows application share the same editable toolbars or even have one?

If you have application developers, and third-party developers, having to create their own independent GUI widgets, and widgets other desktops have had for years at that, then you've got a dog's breakfast interface-wise. Vista and Mac OS X have inheritable APIs and components for doing all this since...forever.


Nonsense, nobody is creating independent GUIs. We only see that on Windows and OS X. People who need editable toolbars create on based on the API in libegg. When there's enough demand for editable toolbars, it'll find its way into GTK or GNOME. You are making a mountain out of an ant hill.

Edited 2007-05-27 03:23

Reply Parent Score: 5

RE[3]: nice work
by kaiwai on Sun 27th May 2007 03:39 in reply to "RE[2]: nice work"
kaiwai Member since:
2005-07-06

If you have application developers, and third-party developers, having to create their own independent GUI widgets, and widgets other desktops have had for years at that, then you've got a dog's breakfast interface-wise. Vista and Mac OS X have inheritable APIs and components for doing all this since...forever.


You obviously haven't used Windows or MacOS X, because both provide toolkits, but we have idiot software developers who go out and create their own widgets and own installers for so-called 'branding' which I hear being thrown around.

The inconsistancy with a so-called 'inheritable APIs and components' definately shows when you've got pea brain half wits creating trash applications like Windows Media Player, Windows Messenger Live, and Microsoft Office - each with its own user interface! where is the consistancy there? I certaintly don't see it!

If you have such an issue with GTK, then why don't you contribute - its majorly undermaned for what needs to be done, there is nothing stopping you from working on merging editable toolbars into gtk and other missing components.

That is the difference between open and closed source; if you're a third party developer in the closed source world, you're at the mercy of the operating system vendor, in the opensource world, you can work to get a needed/required feature in a depedent library yourself. Thats the difference. Its not my fault that third party software vendors are lazy and would sooner 'live it up' than invest into their products for long term profit and competitive advantage.

Reply Parent Score: 5

RE[2]: nice work
by aseigo on Sun 27th May 2007 20:07 in reply to "RE: nice work"
aseigo Member since:
2005-07-06

> Speaking of evince, it's nice to know KDE 4 will
> have a similar application.

we already have a similar application in kde3 ;) it's just getting better in kde4 and already has features on that roadmap.

> Hopefully it will share resources with evince by
> using libpoppler, which AFAIK KDE doesn't do yet.

poppler has been used by kpdf/okular and kviewshell/ligature for some time now. it was a compile time option which you used and depending on the distro and the maturity of poppler in their mind you'd either get a poppler enabled version or one that used another solution.

> Consistency is one of GNOME's strongest features.

yes, gnome has a lot of consistency between things like configuration dialogs in the base set of apps (and it has been getting better in 3rd party apps too). but let's not engage in double speak here; the fact that apps still need to implement toolbar configurability, and that that makes it onto a road map, highlights exactly what the original poster was saying. you're talking about different things (and boy is it annoying when people reply in a conversation using that tactic)

Reply Parent Score: 5