Hey there,
As a (future) candidate for the Google Summer of Code, and a fan and user of Inkscape, I strolled through the ideas page on the website, but I didn't find any mention of a native GUI for OSX.
As far as I can tell, it's not even on the roadmap, which leads me to think that the developing community might not see that a critical or even important.
I, for one, would really like to see that happen. First as a user, because launching X11 on a low-end Mac is just extremely painful and the interface is not always rendered correctly (which kind of negates the possibility of really using Inkscape on OSX sometimes). Secondly, I do think that it could be useful in that there is currently no other free (as in beer) vector editor of quality on OSX, which stays the platform of choice for many 'creatives'.
Finally, as far as I can tell, it looks highly feasible on a technical and temporal standpoint. My only fear (and my main question here), is that I may face an OOo-type situation where the GUI and the engine are so bonded together that using another GUI involves going deep into the general code. It does not seem that this is the case as Inkscape is built on libraries and previous projects, but you never know.
So, I was wondering if that type of project seemed 1) interesting to you (ie : may be a good subject for a SoC participation) and 2) seemed feasible to you as everyday/everyweek/everymonth contributers to the code.
Many thanks in advance for your input !
Sincerely, Tim Anglade
On Wed, 3 May 2006, Timothée Anglade wrote:
Secondly, I do think that it could be useful in that there is currently no other free (as in beer) vector editor of quality on OSX, which stays the platform of choice for many 'creatives'.
What about Synfig? It is far from perfect :) But I played with it and it has potential.
Stefan
Timothée Anglade wrote:
As a (future) candidate for the Google Summer of Code, and a fan and user of Inkscape, I strolled through the ideas page on the website, but I didn't find any mention of a native GUI for OSX.
As far as I can tell, it's not even on the roadmap, which leads me to think that the developing community might not see that a critical or even important.
Actually, this is not a project for Inkscape, but the Gtk library upon which Inkscape is based. It can be found here:
http://developer.imendio.com/wiki/Gtk_Mac_OS_X
Apparently it has made great progress, but it could benefit from any volunteers it can find. (hint, hint)
bob
On Wed, 03 May 2006 00:28:48 +0200, Timothée Anglade wrote:
As a (future) candidate for the Google Summer of Code, and a fan and user of Inkscape, I strolled through the ideas page on the website, but I didn't find any mention of a native GUI for OSX.
For a desktop app like Inkscape a LOT of the code is GUI code. Rewriting all of that, and maintaining it, just for the Mac would be a massive amount of work for little real gain (as most of the developers are on Linux anyway it seems).
Secondly, I do think that it could be useful in that there is currently no other free (as in beer) vector editor of quality on OSX, which stays the platform of choice for many 'creatives'.
I don't see the relevance of this ... if 'creatives' want a free vector editor they can use a platform where one exists (for instance, Linux/BSD/Windows/any other platform Inkscape supports to the needed level)
-mike
Finally, as far as I can tell, it looks highly feasible on a technical and temporal standpoint. My only fear (and my main question here), is that I may face an OOo-type situation where the GUI and the engine are so bonded together that using another GUI involves going deep into the general code. It does not seem that this is the case as Inkscape is built on libraries and previous projects, but you never know.
Can you be more specific?
Inkscape is a C/gtk+ application (where the C was OOPish style C) in the process of moving to C++/gtkmm. Of course, libraries are used for this.
ralf
On May 3, 2006, at 9:29 AM, Ralf Stephan wrote:
Finally, as far as I can tell, it looks highly feasible on a technical and temporal standpoint. My only fear (and my main question here), is that I may face an OOo-type situation where the GUI and the engine are so bonded together that using another GUI involves going deep into the general code. It does not seem that this is the case as Inkscape is built on libraries and previous projects, but you never know.
Can you be more specific?
Inkscape is a C/gtk+ application (where the C was OOPish style C) in the process of moving to C++/gtkmm. Of course, libraries are used for this.
*and* some of those libraries include gtk+, gtkmm and glib. Gotta remember that detail. :-)
One thing to keep in mind is that the bulk of Inkscape code, as a visual editor, is to visually do things. This usually involves integration with the UI widgets.
However, all details aside, I can't see where being "highly feasible" on either a technical or temporal viewpoint is a solid assertion. Separate the UI, and you're left with a simple SVG renderer. And that is already completed. And not even looking into the question of GUI and engine being tied together, just the scope of work to get a native UI implemented is rather enormous. And even if there were not major technical issues, the amount of time from pure grunt-work alone blows out the 'temporal' assertion.
But the good news, as others pointed out, is that there is not active work getting GTK++ itself to be OS X native. This has been ongoing, and thus is a large reason for Inkscape developers not to reinvent the wheel when waiting a little can get it all done for free.
Oops. Major typo there.
That should read "there is *now* active work" not "there is not active work"
On May 3, 2006, at 6:01 PM, Jon A. Cruz wrote:
But the good news, as others pointed out, is that there is not active work getting GTK++ itself to be OS X native. This has been ongoing, and thus is a large reason for Inkscape developers not to reinvent the wheel when waiting a little can get it all done for free.
Okay guys, seems I was really off the target on that idea.
Thanks for your answers.
Tim
On 5/4/06, Jon A. Cruz <jon@...18...> wrote:
Oops. Major typo there. That should read "there is *now* active work" not "there is not active work"
On May 3, 2006, at 6:01 PM, Jon A. Cruz wrote:
But the good news, as others pointed out, is that there is not active work getting GTK++ itself to be OS X native. This has been ongoing, and thus is a large reason for Inkscape developers not to reinvent the wheel when waiting a little can get it all done for free.
On 04/05/06, Timothée Anglade <timothee.anglade@...1261...> wrote:
Okay guys, seems I was really off the target on that idea.
Of course you are not off target.
If you want a top quality drawing application for the Mac OS, note that Coreldraw discontinued theirs a few years ago, and Freehand is set to disappear.
Canvas 8 is available for free, exempli gratia: http://www.paperworlds.com/forums/lofiversion/index.php/t853.html (and a few other places - enquire at your local Macintosh User Group)
The Creature House Expression beta still works: http://wiki.inkscape.org/wiki/index.php/Expression
It is perfectly reasonable to fill the gap left by Freehand with an existing open source application such as Inkscape, to start a new project such as Chlor http://sourceforge.net/projects/chlor/ , xvg http://sourceforge.net/projects/xvg , or PettySVG http://toxicsoftware.com/blog/index.php/weblog/entry/pettysvg/ , or to Open Source a previously closed product such as XaraLX http://www.xaraxtreme.org/developers/documentation/xara_lx_mac_build_instruc... .
There are four or five people who commonly post here on Mac topics, and as I suspect that there are around ten lurkers for every poster, we probably have 25 to 50 Mac devs and testers, and this could be the entire world supply of available talent for such an endeavour. I would guess that a Native Mac Port is seen as important, but not as critical.
You may have already picked up on this suggestion, but if you feel that the Wiki is missing a particular page then you can make yourself a user name and add that page. If it is a good idea, then people will add to it, perhaps in ways that you had not considered.
Speaking personally, I think that there are several things 'missing' from the roadmap, but I am glad to see that Animation is now on at 0.51 and Bug hunt 0.47 (which still leaves 'Rework Layers UI' and 'Blends', for example, as omissions). I hardly dare look at the RFE tracker, I suspect that there are hundreds of valid requests, even after removing duplicates, and despite the natural worry I have of Mongolian Horde http://www.everything2.com/index.pl?node_id=29845 programming I expect that Inkscape, being still a young project, needs to acquire many more devs whose main interest is adding the one feature that interests them, it it would not surprise me if, over the next few years of its life, Inkscape grows to support several hundred devs - something which ought to require some thought and perhaps planning before the size doubles for next time.
Note that your precise comment about the Mac's being used by creatives but not having sound open source applications is made at every mention of Pixen http://www.opensword.org/Pixen/ and Seashore http://sourceforge.net/projects/seashore , I would guess that there are plenty of applications for "creatives" perhaps some boutique or niche, but good enough to fit in for the most part, and stand out where appropriate. As I say, check with your local Macintosh User Group.
Unless otherwise notified, I see no bar to adding milestones to the Map, so 'Groundwork for Native Mac UI' would fit with 'Drawing Feature Enhancements' at 0.48, but I suspect that you will need to add a 0.56 for 'Commit Native Mac Port'.
When you speak of X11, this is very much a three edged sword. X11 support on MacOS X/Darwin is really very good if you want X11; Developments in GTK+ may solve some of your concerns; and being able to use SVG as a platform independent file format is sufficiently refreshing as to counteract the obvious infelicity.
Now, I appreciate that a substantial portion of the Mac community do not want to use X11, and may not agree that this is a good bargain for getting SVG support, but neither point of view trumps the other. I take my hat off to the people at Cupertino who have given us this choice. Further, speak to the people at your local MUG, you will find free as in beer editors (I think that Canvas is best of breed), but people are still getting excellent results from Appleworks and even MacDraw Pro.
You need to look at the archives of the list to see ther extent to which people have discussed the architecture of Inkscape. In practice the 'Engine' and UI are not totally bonded together. I fear that the 'Engine' does use services from GTK+, but this should be resolvable through re-factoring. (I suggest that you allow part of the calendar time of 4 milestones to do this).
You will probably find that most of the frequent committers have given this no thought, the frequent committers will either be scratching their own itch or have other concerns. Maybe it is not that interesting. Now, I have no insight into how the SoC projects are assessed, but if one scale is to weight against ideas which ought to have their implementation under the aegis or auspices of some other organisation then you might find that adding a Cocoa port to Inkscape is affected by that. Certainly I would wonder why Google should should be involved if nobody has stepped up to make a start.
I wouldn't agree that existence of many thousands of lines of GUI code in the current Inkscape projects is good or bad for a Cocoa port. We would write a Cocoa interface (using interface builder for the most part) and plug that into the 'Engine' using an MVC architecture; much as doing a brain transplant means preserving the pryamidal tracts. Do you think that the existence of hundreds of thousands LOC for XUL in Firefox and Mozilla went (or could go) any way towards dissuading the authors of Camino?
Also many of the users of Inkscape are on Windows despite most of the devs using linux: All that is needed is one person with a clear goal and the determination to keep the Cocoa port on track.
You might want to get involved with some of the other projects I have mentioned, perhaps work on GTK+ (I am having difficulty compiling the CUPS backend at the moment), add the documentation that you have adumbrated and perhaps bung the whole of the Inkscape code base into XCode (XCode has support for Test Driven Development, and I am sure that any work you could do on this for the Inkscape project in general would stand you in very good stead when you ask for help or support) and get it to compile. (Had you done that last year, you might have had to start over after the switch to Subversion).
I general, I would say go. I would guess that it is inescapable that you will have to do some planning, but from the outside it is as simple as:
* Work out what you are starting from.
* Work out where you are going to.
* Write down some ideas
* Start developing
I am not sure whether you should work on your own. Assuming that you have the necessary XCode and Interface Builder skills then that sort of purity is helpful. For aught I (or you) know, there could be people trying out these ideas as we speak, and it just needs someone to co-ordinate whatever endeavours are already under way; something that Subversion should make easier.
Ben
On 5/4/06, Jon A. Cruz <jon@...18...> wrote:
Oops. Major typo there.
That should read "there is *now* active work" not "there is not active work"
On May 3, 2006, at 6:01 PM, Jon A. Cruz wrote:
But the good news, as others pointed out, is that there is not active work getting GTK++ itself to be OS X native. This has been ongoing, and thus is a large reason for Inkscape developers not to reinvent the wheel when waiting a little can get it all done for free.
I'd just like to give my support for this idea. I regularly use both OS X and Windows, so I'd very much like to see a native Inkscape for OS X. But I think development efforts would be best directed into projects to port GTK rather than any specific program using GTK.
The currently active project for GTK2 is http://developer.imendio.com/wiki/Gtk_Mac_OS_X
Otherwise, you could end up with the situation of several different developers all working on porting a particular OSS GTK+ app to native OS X when they could be channeling their efforts together into the GTK+ project.
I remember when I first started working with GTK apps on Windows (namely GIMP), it was kludgy and awkward - there was no real interaction with the rest of the OS and it really behaved no different to running a rootless X server. Now, GTK+ on windows has come a long way and apps like the GIMP and Inkscape feel far more native now. I've no doubt that over time this will happen with OS X GTK+ and Mac users will then have access to a wealth of OSS apps that run effectively natively, rather than just the ones that have had enough developers to be able to port successfully.
Cheers Derek
On May 4, 2006, at 8:16 AM, Ben Fowler wrote:
You will probably find that most of the frequent committers have given this no thought, the frequent committers will either be scratching their own itch or have other concerns. Maybe it is not that interesting.
Actually... I'd wager that most have given it a fair bit of thought. And that I've given it quite a lot of thought since my main computer for doing Inkscape work *is* an OS X box. :-)
And in general thought is given to cross-platform issues, as keeping things compatible with Win32 builds has been discussed and has driven decisions for some time now.
Personally, I've always felt that the proper way for Inkscape to be more mac friendly would be to get GTK+ native on OS X, and not divorce it from GTK+ itself. I've not hand much time to give to supporting that, but I'd at least been known for pestering my "mac friends" to lend a hand to various porting efforts.
And again, the newest effort has actually gotten significant traction and progress. It's gone into main GTK+ CVS, and has actually been hitting close to its aggressive targets http://developer.imendio.com/wiki/Gtk_Mac_OS_X/Roadmap
My guess is that we can even start looking at doing non-X11 developer builds of Inkscape once we get 0.44 out the door.
Thanks for the detailed answers guys.
I'm pondering the idea of doing this kind of work on GTK+OSX with the MacLibre/WinLibre project which would make more sense than to submit this idea to an application-driven project like Inkscape.
Although, I must say this kind of work may be way over my head. I feel perfectly capable of doing UI design (and I've done some in the past on small projects), and that was my idea for Inkscape. My initial thought was to contribute by designing a beautiful OSX interface with the latest UI widgets by Apple (transparent drawers, ...) and following their Human Interface guidelines. I had hoped that, taking the rendering area out of the equation (somehow), it would have been possible to do a new, separate interface (buttons, menus, drawers and whatnot) that would call the appropriate methods from the engine.
Going deep down in GTK+ code was not what I had in mind and, having no prior experience with that language I'm concerned that I might not be up to the task (thus my question on whether working on Inkscape only would require going deep in-between GTK+ code and the engine).
I'll try talking to the GTK and MacLibre guys to get their input on that matter.
Many thanks again for your answers and remarks.
Tim
On 5/5/06, Derek Hinchliffe <derek@...1264...> wrote:
On 5/4/06, Jon A. Cruz <jon@...18...> wrote:
Oops. Major typo there.
That should read "there is *now* active work" not "there is not active
work"
On May 3, 2006, at 6:01 PM, Jon A. Cruz wrote:
But the good news, as others pointed out, is that there is not active
work
getting GTK++ itself to be OS X native. This has been ongoing, and
thus is a
large reason for Inkscape developers not to reinvent the wheel when
waiting
a little can get it all done for free.
I'd just like to give my support for this idea. I regularly use both OS X and Windows, so I'd very much like to see a native Inkscape for OS X. But I think development efforts would be best directed into projects to port GTK rather than any specific program using GTK.
The currently active project for GTK2 is http://developer.imendio.com/wiki/Gtk_Mac_OS_X
Otherwise, you could end up with the situation of several different developers all working on porting a particular OSS GTK+ app to native OS X when they could be channeling their efforts together into the GTK+ project.
I remember when I first started working with GTK apps on Windows (namely GIMP), it was kludgy and awkward - there was no real interaction with the rest of the OS and it really behaved no different to running a rootless X server. Now, GTK+ on windows has come a long way and apps like the GIMP and Inkscape feel far more native now. I've no doubt that over time this will happen with OS X GTK+ and Mac users will then have access to a wealth of OSS apps that run effectively natively, rather than just the ones that have had enough developers to be able to port successfully.
Cheers Derek
Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmdlnk&kid%120709&bid&3057&d...http://sel.as-us.falkag.net/sel?cmdlnk&kid%120709&bid&3057&dat%121642 _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On 05/05/06, Timothée Anglade <timothee.anglade@...1261...> wrote:
I'm pondering the idea of doing this kind of work on GTK+OSX with the MacLibre/WinLibre project ...
Do you have the relevant link to the MacLibre project concerned.
Although, I must say this kind of work may be way over my head. I feel perfectly capable of doing UI design [ snip good stuff] ..
I point I neglected to discuss last night was to stress that the ultimate success of the Inkscape project, and no doubt an area of interest to most people here is the quality of the User Interface. In my opinion, no effort should be spared in creating an appropriate and high quality HCI. It has yet to be shown that an OSS project can produce a best of breed UI (I think that it is possible, and that to date, no project has put together all the ingredients needed for success), which is why one suggestion of mine was to achieve a purity of design, and perhaps work alone for a period of time. This is not necessarily the best way to go, but it might enable you to achieve something that you can feel proud of, I think that the French word is fière : joy and elegance; which would count as 'best foot forward' in terms of bringing along the Inkscape project.
On 5/5/06, Derek Hinchliffe <derek@...1264...> wrote:
On 5/4/06, Jon A. Cruz <jon@...18...> wrote:
Oops. Major typo there. That should read "there is *now* active work" not "there is not active
work"
On May 3, 2006, at 6:01 PM, Jon A. Cruz wrote:
But the good news, as others pointed out, is that there is not active
work
getting GTK++ itself to be OS X native. This has been ongoing, and
thus is a
large reason for Inkscape developers not to reinvent the wheel when
waiting
a little can get it all done for free.
I'd just like to give my support for this idea. I regularly use both OS X and Windows, so I'd very much like to see a native Inkscape for OS X. But I think development efforts would be best directed into projects to port GTK rather than any specific program using GTK.
The currently active project for GTK2 is http://developer.imendio.com/wiki/Gtk_Mac_OS_X
Otherwise, you could end up with the situation of several different developers all working on porting a particular OSS GTK+ app to native OS X when they could be channeling their efforts together into the GTK+ project.
I remember when I first started working with GTK apps on Windows (namely GIMP), it was kludgy and awkward - there was no real interaction with the rest of the OS and it really behaved no different to running a rootless X server. Now, GTK+ on windows has come a long way and apps like the GIMP and Inkscape feel far more native now. I've no doubt that over time this will happen with OS X GTK+ and Mac users will then have access to a wealth of OSS apps that run effectively natively, rather than just the ones that have had enough developers to be able to port successfully.
On 5/5/06, Ben Fowler <ben.the.mole@...400...> wrote:
On 05/05/06, Timothée Anglade <timothee.anglade@...1261...> wrote:
I'm pondering the idea of doing this kind of work on GTK+OSX with the MacLibre/WinLibre project ...
Do you have the relevant link to the MacLibre project concerned.
Sure : - WinLibre SoC page : http://www.winlibre.com/wiki/doku.php?id=winlibre_soc_2006:proposals_for_the... - MacLibre page : http://www.winlibre.com/wiki/doku.php?id=maclibre - MacLibre dev page : http://www.winlibre.com/wiki/doku.php?id=winlibre_soc:maclibre
Basically their project is to extend OpenSource to other platforms (Windows and OSX respectively).
[snip of good stuff also]
As far as 're-designing' Inkscape, I sure does sound interesting, but that's not something I would get myself into unless it was strongly demanded by the community. I know for a fact that in most re-designs (be it for websites, apps, logos or whatever) it's useless to do it if there is not a need that is felt by the community. I may feel like Inkscape needs a re-design, you may too, but that's something that would most definitely has to start from a strong signal from the entire dev team.
Tim, looking for a reason to be 'fier'...
On 05/05/06, Timothée Anglade <timothee.anglade@...1261...> wrote:
On 5/5/06, Ben Fowler <ben.the.mole@...400...> wrote:
On 05/05/06, Timothée Anglade <timothee.anglade@...1261...> wrote:
As far as 're-designing' Inkscape, it sure does sound interesting, but that's not something I would get myself into unless it was strongly demanded by the community. I know for a fact that in most re-designs (be it for websites, apps, logos or whatever) it's useless to do it if there is not a need that is felt by the community. I may feel like Inkscape needs a re-design, you may too, but that's something that would most definitely has to start from a strong signal from the entire dev team.
You have, I think, hit the nail on the head, if not squarely. The current (Gtk+) design for Inkscape is good, and changes to it are resisted. Look at the 'Edit' menu which only a mother could love. I suspect that it is easy for OSS projects to reach a local maximum.
If we want to be 'best of breed' then we need to re-think.
We are often urged to do a root and branch redesign - the Firefox model, and like all these endeavours, it will start well.
Personally, I think that just as OSS coding comes from people using the program contributing the bug fixes, the enhancements and new features, so OSS UI design should come about by getting users into the loop. We need tools and social structures so that individual users can fix, enhance and add to the UI.
In the absence of this discipline, I fall back on urging anyone who seems the slightest bit interested into somehow contributing to or testing the UI for Inkscape.
Tim, looking for a reason to be 'fier'...
Sorry, the word in this country is often associated with motherhood, and I wasn't thinking that it was an adjective.
Ben
On Fri, 5 May 2006, Ben Fowler wrote:
Date: Fri, 5 May 2006 11:39:14 +0100 From: Ben Fowler <ben.the.mole@...400...> To: Inkscape Devel List Inkscape-devel@lists.sourceforge.net Subject: Re: [Inkscape-devel] [SoC] Native OSX GUI ?
On 05/05/06, Timothée Anglade <timothee.anglade@...1261...> wrote:
I'm pondering the idea of doing this kind of work on GTK+OSX with the MacLibre/WinLibre project ...
Do you have the relevant link to the MacLibre project concerned.
Although, I must say this kind of work may be way over my head. I feel perfectly capable of doing UI design [ snip good stuff] ..
I point I neglected to discuss last night was to stress that the ultimate success of the Inkscape project, and no doubt an area of interest to most people here is the quality of the User Interface. In
I'm not an expert on the Mac Human Interface Guidelines but I'd like to think they are a stricter superset of the Gnome Human Interface guidelines and that if enough people wanted to Inkscape should be able to meet those high standards on all platforms not just Mac OS.
my opinion, no effort should be spared in creating an appropriate and high quality HCI.
It is interesting you mention "appropriate" since usability is a lot like optimisation and it depends what you consider most appropriate to optimise for. We have disagreements all the time trying to strike a balance between effiency and learnability. There is no one single right answer, at least not until you strictly tie down the question and know exactly what audience you are trying to target.
It has yet to be shown that an OSS project can produce a best of breed UI (I think that it is possible, and that to date, no project has put together all the ingredients needed for success), which is why one suggestion of mine was to achieve a purity of design, and perhaps work alone for a period of time.
Purity of design or inconsistent and more difficult to learn?
As with the more techincal discussions - such as the shared understanding that native GTK for Mac OS X is the only practial way to go - things go more smoothly when a consensus builds and we all pull together. At the moment there is a rough sense of how we all want to Inkscape to have a better/best user interface possible but a clearer vision of how we can all achieve that together would help. Anything which could help us all form a clearer plan and then break that up into smaller shared tasks will really help. Management is an important part of development, something which I think has been a key part of the success of Inkscape so far.
Sincerely
Alan Horkan
Inkscape http://inkscape.org Abiword http://www.abisource.com Open Clip Art http://OpenClipArt.org
Alan's Diary http://advogato.org/person/AlanHorkan/
On 05/05/06, Alan Horkan <horkana@...44...> wrote:
On Fri, 5 May 2006, Ben Fowler wrote:
Date: Fri, 5 May 2006 11:39:14 +0100 From: Ben Fowler <ben.the.mole@...400...>
[ snip ]
It has yet to be shown that an OSS project can produce a best of breed UI (I think that it is possible, and that to date, no project has put together all the ingredients needed for success), which is why one suggestion of mine was to achieve a purity of design, and perhaps work alone for a period of time.
Purity of design or inconsistent and more difficult to learn?
If you think of the best designs in any area that you are familiar with, my guess is that you could name the designer and assert that it came from the brain of one person. That is what I meant by 'working alone' and 'purity of design'. (I was also assuming that everyone on the dev list actually likes making vector drawings - I know that I do; and perhaps had a generous modicum of what Paul Graham calls good taste http://wingware.com/pipermail/py-design-forum/2003-September/000184.html and http://david.shackelford.org/?p=304).
Inconsistent is a loaded word. "Lets be consistent and force all the square pegs into the round holes."
'Difficult to learn' can mean 'easy to use'. One persons 'good' UI (easy to learn) could be the next man's poor design (hard to do good work with).
As with the more techincal discussions - such as the shared understanding that native GTK for Mac OS X is the only practial way to go - things go more smoothly when a consensus builds and we all pull together. At the moment there is a rough sense of how we all want to Inkscape to have a better/best user interface possible but a clearer vision of how we can all achieve that together would help. Anything which could help us all form a clearer plan and then break that up into smaller shared tasks will really help. Management is an important part of development, something which I think has been a key part of the success of Inkscape so far.
Without disagreeing with you too much, you are describing how to reach a local maximum. This is not going to help becoming best of breed. In fact a better way would be for as many people as are willing to produce a design (or merely a mockup in the GIMP) and have the group provide criticism. Perhaps we need to decide whether we should be seeking to be best of breed, or whether a local maximum (nothing need be added, nothing taken away) is good enough. There is a lot to be said for 'good enough'. Perhaps we need to decide how long we can defer such decisions. Perhaps the longer the better. What will people watching the progress of Inkscape (and for that matter the Gimp) think about its UI being and looking unfinished for the next 55 milestones. My answer would be "Hey, our users are happy and they care enough to send feedback".
Ben
Ok, let's try to put this back into context. I understand that as developers, your main concern is the application. I have to be honest and say that as a potential SoC applicant my concerns also match my passion for the project, but I do have an additional time constraint.
Whether that sense of urgency (on my side) jeopardizes the well being of Inkscape is for you to judge, but here is a pre-proposal (nothing formal yet) I'd like to make.
From what has been discussed, it seems some work (assessment of what
has been done, evaluation of needs and interests, optional improvement) could be done on Inkscape's UI. I would be delighted to help with that by maybe conducting a two or three part job as a SoC participant. - Part 1 would include summing up the current UI situation and what has brought it here, evaluate the concerns and needs of users and developers. - Part 2 would consist of doing extensive HCI and usability research to find solutions that could address what has been brought up from Part 1, then doing mock ups, (if possible, several versions), and possibly asking a certain group (users, developers, ... ?) to vote to choose one of them. - Part 3 would optionally be the implementation of theses changes, if any are deemed interesting by the community.
The goal being of course to make out of Inkscape, as Ben said, a "best-of-breed" app that the vector drawing or Open Source communities would be proud of. If no need or concern stems from the first two parts, then this study would at least have the merit to put these questions to sleep by making sure there's no obvious work to be done there, which is not the general opinion as the (limited) discussions here seem to point out.
One last point regarding the team-vs-one guy approach. I'm a firm proponent of the later, because all my experiences in design with a (large-)group have been failures, as it's never possible to have everybody agree on a design or another. What people do agree on are results (in this case, more people coming to use the app and help develop it, less complaints about usability or learnaility). And I think putting trust in someone to do that job and present results almost scientifically (Im using 'almost' because we're talking about design after all !) is the best approach to get results.
Here were my two cents on this.
Tim
On 5/5/06, Ben Fowler <ben.the.mole@...400...> wrote:
On 05/05/06, Alan Horkan <horkana@...44...> wrote:
On Fri, 5 May 2006, Ben Fowler wrote:
Date: Fri, 5 May 2006 11:39:14 +0100 From: Ben Fowler <ben.the.mole@...400...>
[ snip ]
It has yet to be shown that an OSS project can produce a best of breed UI (I think that it is possible, and that to date, no project has put together all the ingredients needed for success), which is why one suggestion of mine was to achieve a purity of design, and perhaps work alone for a period of time.
Purity of design or inconsistent and more difficult to learn?
If you think of the best designs in any area that you are familiar with, my guess is that you could name the designer and assert that it came from the brain of one person. That is what I meant by 'working alone' and 'purity of design'. (I was also assuming that everyone on the dev list actually likes making vector drawings - I know that I do; and perhaps had a generous modicum of what Paul Graham calls good taste http://wingware.com/pipermail/py-design-forum/2003-September/000184.html and http://david.shackelford.org/?p=304).
Inconsistent is a loaded word. "Lets be consistent and force all the square pegs into the round holes."
'Difficult to learn' can mean 'easy to use'. One persons 'good' UI (easy to learn) could be the next man's poor design (hard to do good work with).
As with the more techincal discussions - such as the shared understanding that native GTK for Mac OS X is the only practial way to go - things go more smoothly when a consensus builds and we all pull together. At the moment there is a rough sense of how we all want to Inkscape to have a better/best user interface possible but a clearer vision of how we can all achieve that together would help. Anything which could help us all form a clearer plan and then break that up into smaller shared tasks will really help. Management is an important part of development, something which I think has been a key part of the success of Inkscape so far.
Without disagreeing with you too much, you are describing how to reach a local maximum. This is not going to help becoming best of breed. In fact a better way would be for as many people as are willing to produce a design (or merely a mockup in the GIMP) and have the group provide criticism. Perhaps we need to decide whether we should be seeking to be best of breed, or whether a local maximum (nothing need be added, nothing taken away) is good enough. There is a lot to be said for 'good enough'. Perhaps we need to decide how long we can defer such decisions. Perhaps the longer the better. What will people watching the progress of Inkscape (and for that matter the Gimp) think about its UI being and looking unfinished for the next 55 milestones. My answer would be "Hey, our users are happy and they care enough to send feedback".
Ben
Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmdlnk&kid%120709&bid&3057&d... _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
I'll make some comments on this, but I think that you actually want someone closer to the SoC to pick this one up
On 05/05/06, Timothée Anglade <timothee.anglade@...1261...> wrote:
Ok, let's try to put this back into context. I understand that as developers, your main concern is the application. I have to be honest and say that as a potential SoC applicant my concerns also match my passion for the project, but I do have an additional time constraint.
That is 'our'.
Whether that sense of urgency (on my side) jeopardizes the well being of Inkscape is for you to judge, but here is a pre-proposal (nothing formal yet) I'd like to make.
As Inkscape is GPL'd little short of a long nuclear winter would jeopardise it. The worst that might happen is that some svn commits might need to be rolled back - the work of a moment.
[ snip ]
- Part 3 would optionally be the implementation of theses changes, if
any are deemed interesting by the community.
That is right. You are free to implement (and distribute) any changes you fancy, but only those that create some interest will be survive.
The goal being of course to make out of Inkscape, as Ben said, a "best-of-breed" app that the vector drawing or Open Source communities would be proud of.
I wouldn't necessarily push for "best of breed" if some other prize winning category were more achievable or in some sense better. "His sins were scarlet but his books were read". I would like Inkscape to: Be capable of accepting feedback, Be useful, Be chosen by the discriminating, Be capable of doing things that its authors had not thought of.
I think there is room for several editors, and in fact Inkscape as a pure SVG editor could take second place to Sodipodi if that became a general purpose editor with similar abilities.
I am fairly sure that there is room for editors specifically for icons, and something like XaraLX which also does bitmap editing.
One last point regarding the team-vs-one guy approach. I'm a firm proponent of the later, because all my experiences in design with a (large-)group have been failures, as it's never possible to have everybody agree on a design or another. What people do agree on are results (in this case, more people coming to use the app and help develop it, less complaints about usability or learnability). And I think putting trust in someone to do that job and present results almost scientifically (I'm using 'almost' because we're talking about design after all !) is the best approach to get results.
It is possible for a 'large group' to agree on one person's being the architect, but I wouldn't bet an OSS project on that. I think that Qmail works like that, and Cyrus and Arch.
* To encourage developers, one needs to have a build system that doesn't break, sound instructions, mailing lists, bug trackers and so on. The code needs to look as though no one is going to jump on you for hacking on it. Big "up front" design http://xp.c2.com/BigDesignUpFront.html needs to approached with caution, see http://www.agilemodeling.com/essays/bmuf.htm http://butunclebob.com/ArticleS.UncleBob.JoelOnXp and should be avoided if it creates a barrier preventing a hcker from jumping in and hacking. The code needs to sufficiently well written that it can be modified with little chance of breaking something else.
* Yes, I would like that subset of people who use vector drawing programs every day and do coding to come and hack on Inkscape, although there are quite a lot of people in that category, the supply is limited, and I don't claim to know how to recruit for Inkscape!
* We are going to get complaints (bug reports) for as long as new features are being added, new people are picking up Inkscape and it is being put to new uses. By and large, OSS is not shelfware.
Arguably, we need some form of organisation so that such reports are analysed and the necessary changes and fixes are put into the code and documentation, and tutorials and screenshots provided. Maybe the total number of open reports looks large, but my understanding is that Inkscape, whilst still a youthful project, is becoming more mature, and serious code defects do not remain long.
* Personally, I would like to see a way of comparing our interface with the Gimp. I would vote for proposals that entailled interface elements that exist in both applications (Layers, Colours, Export) being either very similar and actually identical if possible, or quite distinct.
Also a group can agree on a Highest Common Subset approach - include all those features with no negative votes - but this often leads to a mediocre result and has to be used with discretion.
Hope this helps, but I have wandered off your topic again ...
Ben.
On 5/5/06, Ben Fowler <ben.the.mole@...400...> wrote:
On 05/05/06, Alan Horkan <horkana@...44...> wrote:
On Fri, 5 May 2006, Ben Fowler wrote:
Date: Fri, 5 May 2006 11:39:14 +0100 From: Ben Fowler <ben.the.mole@...400...>
[ snip ]
It has yet to be shown that an OSS project can produce a best of breed UI (I think that it is possible, and that to date, no project has put together all the ingredients needed for success), which is why one suggestion of mine was to achieve a purity of design, and perhaps work alone for a period of time.
Purity of design or inconsistent and more difficult to learn?
If you think of the best designs in any area that you are familiar with, my guess is that you could name the designer and assert that it came from the brain of one person. That is what I meant by 'working alone' and 'purity of design'. (I was also assuming that everyone on the dev list actually likes making vector drawings - I know that I do; and perhaps had a generous modicum of what Paul Graham calls good taste http://wingware.com/pipermail/py-design-forum/2003-September/000184.html and http://david.shackelford.org/?p=304).
Inconsistent is a loaded word. "Lets be consistent and force all the square pegs into the round holes."
'Difficult to learn' can mean 'easy to use'. One persons 'good' UI (easy to learn) could be the next man's poor design (hard to do good work with).
As with the more techincal discussions - such as the shared understanding that native GTK for Mac OS X is the only practial way to go - things go more smoothly when a consensus builds and we all pull together. At the moment there is a rough sense of how we all want to Inkscape to have a better/best user interface possible but a clearer vision of how we can all achieve that together would help. Anything which could help us all form a clearer plan and then break that up into smaller shared tasks will really help. Management is an important part of development, something which I think has been a key part of the success of Inkscape so far.
Without disagreeing with you too much, you are describing how to reach a local maximum. This is not going to help becoming best of breed. In fact a better way would be for as many people as are willing to produce a design (or merely a mockup in the GIMP) and have the group provide criticism. Perhaps we need to decide whether we should be seeking to be best of breed, or whether a local maximum (nothing need be added, nothing taken away) is good enough. There is a lot to be said for 'good enough'. Perhaps we need to decide how long we can defer such decisions. Perhaps the longer the better. What will people watching the progress of Inkscape (and for that matter the Gimp) think about its UI being and looking unfinished for the next 55 milestones. My answer would be "Hey, our users are happy and they care enough to send feedback".
Okay, I'm going to top post :)
I like the idea of doing research and writing things up on the UI. But, I think that Google is probably more interested in code... Now, we can fix that :) Currently the keybindings and menus are both generated via user specified XML files. There is no reason the toolbars couldn't be the same. While that isn't the "whole UI", those are the major portions, and I think adding that configurability might be a direction that Google would support. Plus, even if all the developers hate your redesign, users could still use it by putting the XML files in their home directories.
--Ted
On Fri, 5 May 2006, Timothée Anglade wrote:
Ok, let's try to put this back into context. I understand that as developers, your main concern is the application. I have to be honest and say that as a potential SoC applicant my concerns also match my passion for the project, but I do have an additional time constraint.
Whether that sense of urgency (on my side) jeopardizes the well being of Inkscape is for you to judge, but here is a pre-proposal (nothing formal yet) I'd like to make.
From what has been discussed, it seems some work (assessment of what has been done, evaluation of needs and interests, optional improvement) could be done on Inkscape's UI. I would be delighted to help with that by maybe conducting a two or three part job as a SoC participant.
- Part 1 would include summing up the current UI situation and what
has brought it here, evaluate the concerns and needs of users and developers.
- Part 2 would consist of doing extensive HCI and usability research
to find solutions that could address what has been brought up from Part 1, then doing mock ups, (if possible, several versions), and possibly asking a certain group (users, developers, ... ?) to vote to choose one of them.
- Part 3 would optionally be the implementation of theses changes, if
any are deemed interesting by the community.
The goal being of course to make out of Inkscape, as Ben said, a "best-of-breed" app that the vector drawing or Open Source communities would be proud of. If no need or concern stems from the first two parts, then this study would at least have the merit to put these questions to sleep by making sure there's no obvious work to be done there, which is not the general opinion as the (limited) discussions here seem to point out.
One last point regarding the team-vs-one guy approach. I'm a firm proponent of the later, because all my experiences in design with a (large-)group have been failures, as it's never possible to have everybody agree on a design or another. What people do agree on are results (in this case, more people coming to use the app and help develop it, less complaints about usability or learnaility). And I think putting trust in someone to do that job and present results almost scientifically (Im using 'almost' because we're talking about design after all !) is the best approach to get results.
Here were my two cents on this.
Tim
On 5/5/06, Ben Fowler <ben.the.mole@...400...> wrote:
On 05/05/06, Alan Horkan <horkana@...44...> wrote:
On Fri, 5 May 2006, Ben Fowler wrote:
Date: Fri, 5 May 2006 11:39:14 +0100 From: Ben Fowler <ben.the.mole@...400...>
[ snip ]
It has yet to be shown that an OSS project can produce a best of breed UI (I think that it is possible, and that to date, no project has put together all the ingredients needed for success), which is why one suggestion of mine was to achieve a purity of design, and perhaps work alone for a period of time.
Purity of design or inconsistent and more difficult to learn?
If you think of the best designs in any area that you are familiar with, my guess is that you could name the designer and assert that it came from the brain of one person. That is what I meant by 'working alone' and 'purity of design'. (I was also assuming that everyone on the dev list actually likes making vector drawings - I know that I do; and perhaps had a generous modicum of what Paul Graham calls good taste http://wingware.com/pipermail/py-design-forum/2003-September/000184.html and http://david.shackelford.org/?p=304).
Inconsistent is a loaded word. "Lets be consistent and force all the square pegs into the round holes."
'Difficult to learn' can mean 'easy to use'. One persons 'good' UI (easy to learn) could be the next man's poor design (hard to do good work with).
As with the more techincal discussions - such as the shared understanding that native GTK for Mac OS X is the only practial way to go - things go more smoothly when a consensus builds and we all pull together. At the moment there is a rough sense of how we all want to Inkscape to have a better/best user interface possible but a clearer vision of how we can
all
achieve that together would help. Anything which could help us all form
a
clearer plan and then break that up into smaller shared tasks will really help. Management is an important part of development, something which I think has been a key part of the success of Inkscape so far.
Without disagreeing with you too much, you are describing how to reach a local maximum. This is not going to help becoming best of breed. In fact a better way would be for as many people as are willing to produce a design (or merely a mockup in the GIMP) and have the group provide criticism. Perhaps we need to decide whether we should be seeking to be best of breed, or whether a local maximum (nothing need be added, nothing taken away) is good enough. There is a lot to be said for 'good enough'. Perhaps we need to decide how long we can defer such decisions. Perhaps the longer the better. What will people watching the progress of Inkscape (and for that matter the Gimp) think about its UI being and looking unfinished for the next 55 milestones. My answer would be "Hey, our users are happy and they care enough to send feedback".
Ben
Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmdlnk&kid%120709&bid&3057&d... _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&da... _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
- Part 2 would consist of doing extensive HCI and usability research
to find solutions that could address what has been brought up from Part 1, then doing mock ups, (if possible, several versions), and possibly asking a certain group (users, developers, ... ?) to vote to choose one of them.
- Part 3 would optionally be the implementation of theses changes, if
any are deemed interesting by the community.
I have read through some SoC documents and i would say what is missing is between your Part 2 and 3: a list of things you want to write, and the respective date when you think to be finished.
Without this, you have exactly zero chances, as far as I understand.
ralf
Okay, here's my take...
On 5/5/06, ted@...11... <ted@...11...> wrote:
Okay, I'm going to top post :)
I like the idea of doing research and writing things up on the UI. But, I think that Google is probably more interested in code...
I do understand that it's called the "Summer of _Code_", but I've looked over the terms, and they define the scope of the project in only two places : 'The Summer of Code is a program in which Google provides student developers with a stipend to create new open source programs or to help currently established projects.' AND 'The goals of the Summer of Code program are to create new developers, support existing open source projects and developers, and to provide students in Computer Science and related fields the opportunity to do work related to their academic pursuits during the summer.'
I understand your point of view, and I agree that they most certainly expect code, but I don't know anyone that would define a 'developer' (the term they use) as a code-producer only (or even, mainly)
On 5/5/06, Ralf Stephan <ralf@...748...> wrote:
I have read through some SoC documents and i would say what is missing is between your Part 2 and 3: a list of things you want to write, and the respective date when you think to be finished.
Without this, you have exactly zero chances, as far as I understand.
That can be included in the proposal. Of course it won't be 'I'll implement this specific function here at this point' but rather 'the work will focus on rewriting unit X, and implementing new interfaces for menus A and B, the extension of which will depend of the first and second part results'.
I understand both points are highly debatable and may hold Google off, but from my (limited) knowledge of the process, I didn't understand that they were that involved in the selection process. Does that type of proposal (admittedly vague, but with strong and precise checkpoints and deliverable reports) would hold SoC deciders for Inkscape off too ?
Tim
On Fri, 2006-05-05 at 12:27 -0500, ted@...11... wrote:
Okay, I'm going to top post :)
I like the idea of doing research and writing things up on the UI. But, I think that Google is probably more interested in code...
Personally, I think doing (potentially major) UI refactoring as an SoC project is just asking for a lot of unnecessary conflict. I think it's just subjective enough that the combination of a tight deadline and cash could make things ugly.
-mental
On May 5, 2006, at 5:07 AM, Alan Horkan wrote:
I'm not an expert on the Mac Human Interface Guidelines but I'd like to think they are a stricter superset of the Gnome Human Interface guidelines and that if enough people wanted to Inkscape should be able to meet those high standards on all platforms not just Mac OS.
Remember, though, there is a large driving factor with the Mac OS UI guidelines:
What will make a pretty presentation for Steve Jobs' keynote?
That's only half in jest. Too much emphasis has been given at times to the wrong driving factors (their single-app-on-screen paradigm was one very obvious example). Just keep that in mind and take their things with a grain of salt. Remember, we'll want the good functional stuff, not the "pretty up on stage" or "keep brand identity" stuff.
On May 5, 2006, at 8:29 AM, Timothée Anglade wrote:
- Part 3 would optionally be the implementation of theses changes, if
any are deemed interesting by the community.
I think there might be some issue with this, as we're re-working things to make the UI different by changing the underlying structure. Once things are changed internally, then visible UI changes can go hog-wild. Any visible work attacked before that, though, may be redundant or more complicated.
One good example is the layers dialog. It's fairly easy to hack together. However, it's not been finished yet as it takes a solid behind-the-scenes abstraction and data model implementation to do it "right". So all the work on that behind-the-scenes stuff seems to show no visible effects. However, once that's been completed, then tweaking the UI to show all sorts of fund stuff will suddenly just appear.
Then again, certain internal fixup might be in place by the time SoC starts, thus allowing more to happen.
participants (11)
-
unknown＠example.com -
Alan Horkan -
Ben Fowler -
Bob Jamison -
Derek Hinchliffe -
Jon A. Cruz -
MenTaLguY -
Mike Hearn -
Ralf Stephan -
Stefan de Konink -
Timothée Anglade