Hey All,
So I think we need to discuss a few things related to development.
1) Regarding the irc dev meeting it appears that two weeks from today on 02/25 at 0800 UTC is the time that worked the best for the most people. Everyone, please put that on your calendar.
2) We're close to cutting 0.48.3, given the state of 0.49, we will also pursue 0.48.4.
3) We need to think seriously about GTK3 at some point. We may want to create a GTK3 branch sooner rather than later to begin that work. It would be good to get other people's thoughts on this. Do we want to take on A) 3 active development branches and B) 2 active refactoring branches. I will note that I don't believe there is a full set of GTK3 libs available for win32 yet and have no idea about the status on OSX.
Cheers, Josh
P.S. Tavmjong, I cc-ed you explicitly because you didn't put the time we ended up with as available. Any chance it can be made to work?
On 11 February 2012 18:52, Josh Andler <scislac@...400...> wrote:
- We need to think seriously about GTK3 at some point. We may want to
create a GTK3 branch sooner rather than later to begin that work. It would be good to get other people's thoughts on this. Do we want to take on A) 3 active development branches and B) 2 active refactoring branches. I will note that I don't believe there is a full set of GTK3 libs available for win32 yet and have no idea about the status on OSX.
There's still plenty to do before we start a gtk3 branch... really, we need to ensure that we can build cleanly against Gtk+ 2.24 with GTK_DISABLE_DEPRECATED defined before we do anything else. The three biggest blockers at the moment, I think, are: * Get rid of all traces of GtkObject... replace it with GObject or GtkWidget as appropriate * Get rid of all uses of GtkOptionMenu, GtkTree and GtkCList. Replace all of them with GtkTreeView * Get rid of GtkRuler. There is no replacement, so we will need to import all the deprecated Gtk code into Inkscape.
I'll continue sorting out more of the easy/boring fixes, but I'll soon need some help from more experienced Gtk app developers! Once we have sorted out all these deprecation issues, we can start the switch over to Gtk3.
Cheers,
AV
On Sat, Feb 11, 2012 at 11:11 AM, Alex Valavanis <valavanisalex@...400...> wrote:
There's still plenty to do before we start a gtk3 branch... really, we need to ensure that we can build cleanly against Gtk+ 2.24 with GTK_DISABLE_DEPRECATED defined before we do anything else. The three biggest blockers at the moment, I think, are:
- Get rid of all traces of GtkObject... replace it with GObject or
GtkWidget as appropriate
- Get rid of all uses of GtkOptionMenu, GtkTree and GtkCList. Replace
all of them with GtkTreeView
- Get rid of GtkRuler. There is no replacement, so we will need to
import all the deprecated Gtk code into Inkscape.
I should have elaborated. By saying sooner rather than later, I wasn't meaning immediately. :) The deprecated stuff needs to be handled first, but we still have to take http://wiki.inkscape.org/wiki/index.php/Tracking_Dependencies into consideration. With that, trunk can't require anything above 2.22 until 9/15 of this year.
Since I am unsure if the goal of making changes to achieve "disable deprecated" being successful requires anything actually included in 2.24, that was why I mentioned the possibility of sooner rather than later. Basically, that branch would start by getting GTK2 requirements met that we may not be able to do in trunk due to project policy. If there's nothing that requires 2.24, it's obviously a non-issue about branching in the near-ish future as it could all still be handled in trunk for a while.
Cheers, Josh
On Feb 11, 2012, at 12:17 PM, Josh Andler wrote:
I should have elaborated. By saying sooner rather than later, I wasn't meaning immediately. :) The deprecated stuff needs to be handled first, but we still have to take http://wiki.inkscape.org/wiki/index.php/Tracking_Dependencies into consideration. With that, trunk can't require anything above 2.22 until 9/15 of this year.
Since I am unsure if the goal of making changes to achieve "disable deprecated" being successful requires anything actually included in 2.24, that was why I mentioned the possibility of sooner rather than later. Basically, that branch would start by getting GTK2 requirements met that we may not be able to do in trunk due to project policy. If there's nothing that requires 2.24, it's obviously a non-issue about branching in the near-ish future as it could all still be handled in
I think, as Alex highlighted, we'll have a natural progression to getting compatible with 3.x.
It's looking like getting compatible with 2.x and 3.x both will allow a few things, including getting to native OSX.
So I think the next immediate step is working on cleaning up to get to GTK3 compatibility (but not dependence).
Then the second step should be working with native the OS X version of GTK. That GTK work is going on in the 3.x line, and is probably the point that will give us the most user benefit in the near term. This probably can be done a bit in parallel with the general 3.x compatibility cleanup.
Another thing we will get with supporting GTK3 is multipointer (MPX) and then multitouch support. However, many parts of our internals will need to get refactored to work well in those areas. This also is related to much of what needs to get cleaned up for multithreaded support, etc. So I think this sort of cleanup will be helpful for many things. It also will clear up some entanglements that get in the way of new code and/or functionality.
Finally I think we can then focus on a few GTK3 specifics and later on dropping GTK2 compatibility.
That then gives these rough phases:
* GTK_DISABLE_DEPRECATED / GTK3 compatibility ** few simple #ifdefs to keep 2.22 compatibility * Work on native OSX GTK. * Tool/context/global cleanup. * Leverage MPX * Add targeted GTK3-based features * Drop GTK2 compatibility
Looking through our current codebase and the various changes we will need to be making, nothing really jumps out that flags needing a formal branching (aka nothing more than the normal local branches devs do now when working towards trunk). This strikes me very similar to our early efforts to move from C to C++. We tried the whole "new code" branch thing, but that didn't pan out. Instead just steady incremental improvements in trunk turned out to be far more successful.
2012/2/11 Jon Cruz <jon@...18...>:
Another thing we will get with supporting GTK3 is multipointer (MPX) and then multitouch support. However, many parts of our internals will need to get refactored to work well in those areas. This also is related to much of what needs to get cleaned up for multithreaded support, etc.
That's something I wondered about. Inkscape is generally not usable with touchscreen devices due to its interface design, which often requires precise manipulation and clicking on areas which are a few pixels wide. I also doubt whether any significant number of people can productively work with 2 traditional mice at once. Is there actually any real benefit to be gained from MPX support?
Regards, Krzysztof
2012/2/11 Krzysztof Kosiński <tweenk.pl@...400...>:
2012/2/11 Jon Cruz <jon@...18...>:
Another thing we will get with supporting GTK3 is multipointer (MPX) and then multitouch support. However, many parts of our internals will need to get refactored to work well in those areas. This also is related to much of what needs to get cleaned up for multithreaded support, etc.
That's something I wondered about. Inkscape is generally not usable with touchscreen devices due to its interface design, which often requires precise manipulation and clicking on areas which are a few pixels wide. I also doubt whether any significant number of people can productively work with 2 traditional mice at once. Is there actually any real benefit to be gained from MPX support?
Using fingers to zoom or (maybe one day) rotate the canvas is one area. There could be other interesting applications in terms of tool usage and such... the Tweak tool (after refactoring) for example could get really powerful on a touch surface. Jon mentioned multiple users on one machine in one document as a use case with multiple mice when we were at SCaLE.
Cheers, Josh
On Sun, 2012-02-12 at 02:42 +0100, Krzysztof Kosiński wrote:
That's something I wondered about. Inkscape is generally not usable with touchscreen devices due to its interface design, which often requires precise manipulation and clicking on areas which are a few pixels wide. I also doubt whether any significant number of people can productively work with 2 traditional mice at once. Is there actually any real benefit to be gained from MPX support?
Those are a few very good questions.
The first point is that multitouch is something very different from multipointer (aka MPX). Both do happen to come from XInput2, but are distinct technologies.
Next is that we really do need to improve the UI so that it *can* be used on touchscreen devices. Much of that can come from a user selecting an appropriate GTK theme for touch, and Inkscape following the user preferences. However there are improvements that would help not only touch interfaces, but tablet use also. We also are seeing the number of touch capable notebooks and tablets grow, so being able to take advantage of those is good.
As a second touch issue, we can gain a lot from supporting common multitouch gestures. As Josh mentioned, zoom, pan, rotate, etc. are all common expected gestures nowadays. Other basic gestures can be included, and they can all be used to supplement the current interface. That is, using them does not require the main UI to be changed from what it currently is. And finally it is good to keep in mind that external touch devices are easy to buy and hook up. Even Apple's magic trackpad is well supported on Linux.
Now on to some MPX items.
It's not really as much about a single user with two mice. MPX just as easily works for a single Wacom user with a single pen and a mouse/puck on the same tablet. Or two pens. Much of the commercial software out there with tablet support already handles mulipointer, at least when it comes to Wacoms. So graphics professionals are already used to such workflows.
The next use case, that Josh mentioned, is with more than one person on the same document. For one case, Dave Crossland was asking about this for the font design workshops he's been running. Another common request has been for hands-on tutorials and training.
And then there is a common case for tablet owners where they can be using the stylus and tablet with their dominant hand, and want to use their normal mouse to work the UI buttons, etc. This can be especially handy when the keyboard has been moved to make room for the tablet.
On Feb 11, 2012 2:56 PM, "Jon Cruz" <jon@...18...> wrote:
I think, as Alex highlighted, we'll have a natural progression to getting compatible with 3.x.
I didn't think I said anything differently, I personally think that the less ifdef'd code we have, the better. Also, I want to point out that developers come and go. If we have someone who is really inspired to craft up GTK3-only widgets for us, why deny them a proper official branch to work in? Personal branches and patches in our bug tracker are seemingly where things go to die.
So I think the next immediate step is working on cleaning up to get to GTK3 compatibility (but not dependence).
Again, I don't think I anything differently. I didn't propose abandoning GTK2 compatibility ASAP. I didn't say let's jump right to dependence in trunk, as I think that's a poor idea. But I think we need a place that is safe for people to put it if they're inspired to take the task on. Also, having a safe testing ground where things are *allowed* to have non-ancient library requirements is appealing, it's a way to provide more interesting things to the bleeding edge testing community as well.
Then the second step should be working with native the OS X version of GTK. That GTK work is going on in the 3.x line, and is probably the point that will give us the most user benefit in the near term. This probably can be done a bit in parallel with the general 3.x compatibility cleanup.
A majority of our users aren't on OSX. It's not mathematically possible to get the most user benefit from targeting the number 3 group of users explicitly. I'm not saying it isn't important to address, but definitely not something that necessarily needs any more priority than addressing Windows users needs. Performance enhancements that affect all users would give the most user benefit. Startup speed for example wouldn't be a bad area to improve (or just accept the fact that no one will every address it and just implement a splash screen already). Performance degradation after extended periods of usage as well. Better performance when dealing with larger files. The thing you mentioned about us traversing defs multiple times as apposed to only once. Crash bugs, etc.
I wouldn't be surprised if we had more overall users interested in us addressing coordinates or even a proper "layer/object dialog" than the number of overall OSX users. Please don't use "most user benefit" so vaguely in the future to justify catering to a small section of our audience. Again, it needs to be addressed, I recognize the importance to that group and how truly unnatural it feels.
I will be sure to add discussion of viability and/or desire for officially sanctioned branches as opposed to personal branches. At the very least, it might be of interest to have a "staging" branch where all changes people want to commit to trunk after a release can reside. It allows people to work on new stuff in an official branch while the bug hunt happens. I'm bringing this up from the "it's how we can possibly have tighter/regular releases on a schedule" angle.
After one more reply, I'm done with this discussion until the irc meeting.
Cheers, Josh
On Sat, 2012-02-11 at 18:45 -0800, Josh Andler wrote:
A majority of our users aren't on OSX. It's not mathematically possible to get the most user benefit from targeting the number 3 group of users explicitly. I'm not saying it isn't important to address, but definitely not something that necessarily needs any more priority than addressing Windows users needs.
Ah, this was one issue that I thought needed to be called out explicitly.
We have far fewer users on OSX precisely because we are not native. We also have a much larger natural target user base on OSX because of the general perception of appropriateness for artistic work.
Even at SCALE, I had many people come up and ask for a native OSX version so they could start using it and start telling others to use it. This included people in education and even professional consultants to companies where Libre software would be a very good fit.
On Sat, Feb 11, 2012 at 9:51 PM, Jon A. Cruz <jon@...18...> wrote:
On Sat, 2012-02-11 at 18:45 -0800, Josh Andler wrote:
A majority of our users aren't on OSX. It's not mathematically possible to get the most user benefit from targeting the number 3 group of users explicitly. I'm not saying it isn't important to address, but definitely not something that necessarily needs any more priority than addressing Windows users needs.
Ah, this was one issue that I thought needed to be called out explicitly.
We have far fewer users on OSX precisely because we are not native. We also have a much larger natural target user base on OSX because of the general perception of appropriateness for artistic work.
Yes, they tend to be snobs. We have far fewer users on OSX because they expect perfection 100% of the time. They also as a majority tend to equate spending money to quality. We could provide the most integrated and most usable product, but free will always taint a good percentage of that crowd.
Even at SCALE, I had many people come up and ask for a native OSX version so they could start using it and start telling others to use it.
I had a couple people I talked to as well who had the same issue, I recognize it. I also had people tell me about the gtkrecent issue that is exposed under Unity with the recent files list. I also had people talk to me about a couple of dialogs on Windows (file open/save as well as the print dialog). The numbers didn't favor any camp and I spent more time at the booth than anyone including my early leave on Sunday.
Cheers, Josh
On Feb 12, 2012, at 1:49 AM, Josh Andler wrote:
On Sat, Feb 11, 2012 at 9:51 PM, Jon A. Cruz <jon@...18...> wrote:
On Sat, 2012-02-11 at 18:45 -0800, Josh Andler wrote:
A majority of our users aren't on OSX. It's not mathematically possible to get the most user benefit from targeting the number 3 group of users explicitly. I'm not saying it isn't important to address, but definitely not something that necessarily needs any more priority than addressing Windows users needs.
Ah, this was one issue that I thought needed to be called out explicitly.
We have far fewer users on OSX precisely because we are not native. We also have a much larger natural target user base on OSX because of the general perception of appropriateness for artistic work.
Yes, they tend to be snobs.
Sorry you're having such a bad day. Insulting a small but not insignificant (I suspect) user group will certainly do wonders for 'sales' and participation.
We have far fewer users on OSX because they expect perfection 100% of the time.
Acknowledging (and agreeing with) your rousing endorsement of OSX (100% perfection - wow), I think that one problem not unique to Inkscape is that most OSX users just don't have the slightest interest in how their systems function - as most of us that subscribe to this board probably do - they just want things to work simply and reliably, to look good, and to use the OSX interface that they have just about learned how to use (X11, what''s that?).
They also as a majority tend to equate spending money to quality.
Not so at all. A popular myth. They just buy what they like. And by and large, the competition isn't catching up very fast. Compare the price of APPL and MSFT.
We could provide the most integrated and most usable product, but free will always taint a good percentage of that crowd.
As a long standing member of 'that crowd' I find this expression of disdain quite inappropriate. If there was an OSX native version of Inkscape that worked well most of the time it would be immensely popular. I use Inkscape exclusively for my modest graphics needs. It's a brilliant application and I can't imagine needing anything more capable. But I have to mentally switch to 'DOS' mode to do it and remember that 'control' is now 'command'. No big deal you say - kinda like going to the UK and remembering to drive on the left - but just that minor aggravation is enough to put off my partner who will only use Inkscape under duress. I'm not a developer in any way, so much of the discussion here goes right over my head. But it seems there are several open source communities that do a decent job of supporting OSX users. GIMP comes to mind. Or NeoOffice. Or QGIS and GRASS. Firefox is pretty popular with OSX users too.
The point is, Inkscape does seem to struggle a bit with OSX. I've tried to participate in some of the packaging efforts of an OSX bundle in the past, and just that is incredibly difficult (for me anyway). I don't have an answer, other than to encourage those of you that make the decisions to at least maintain a steady focus on OSX. There is a big (maybe even wealthy ; ) ) prospective user group out there. I'll do what little I can, but will continue to rely on and be very grateful to those that are making it work as well as it does. You have my greatest admiration! (putting aside the bad-day rants)
Best
Stu
Apple [ ] to OSX in 30+ short years
I just woke up, so it's a great time to make important decisions.
Thank you Stuart (who hasn't chimed in on any discussion before that I'm aware of), you've changed my mind and made me see the light about why we should focus on OSX users more than any other user group. It's obvious that my more irritated than necessary response to Jon's insistence for "arguing for the sake of arguing" was uncalled for.
At the moment it's currently feeling like I'm probably overdue for finding greener pastures. I'm considering relinquishing all of my project responsibilities from being on the board, the released manager, perma-gsoc administrator, to all of the other things I do. It's been fun, but I don't know that it's worth it anymore.
I'll have a decision by tomorrow morning after I've had some time to mull it over... but for now I'm leaning towards farewell.
Cheers, Josh
On Sun, Feb 12, 2012 at 8:31 PM, Stuart Edwards wrote:
But it seems there are several open source communities that do a decent job of supporting OSX users. GIMP comes to mind.
GIMP? Hmmm. Lisa does marvelous work with the gimponosx project indeed, but I've yet to recall one single time I saw her around. Mostly she just makes things work in background. So no, both Windows and Mac ports aren't contributed by the team, and in my book community more or less equals to users.
Alexandre Prokoudine http://libregraphicsworld.org
On Sat, 2012-02-11 at 21:51 -0800, Jon A. Cruz wrote:
We have far fewer users on OSX precisely because we are not native. We also have a much larger natural target user base on OSX because of the general perception of appropriateness for artistic work.
Even at SCALE, I had many people come up and ask for a native OSX version so they could start using it and start telling others to use it. This included people in education and even professional consultants to companies where Libre software would be a very good fit.
Perhaps the large number of people wouldn't mind terribly putting some money into a hat and funding some developer time at one of the many excellent coding houses?
Inkscape could do with some more developer time and I'm sure there are developers out there who wouldn't mind getting paid to do it.
Martin,
On Sat, 2012-02-11 at 10:52 -0800, Josh Andler wrote:
Hey All,
So I think we need to discuss a few things related to development.
- Regarding the irc dev meeting it appears that two weeks from today
on 02/25 at 0800 UTC is the time that worked the best for the most people. Everyone, please put that on your calendar.
- We're close to cutting 0.48.3, given the state of 0.49, we will
also pursue 0.48.4.
- We need to think seriously about GTK3 at some point. We may want to
create a GTK3 branch sooner rather than later to begin that work. It would be good to get other people's thoughts on this. Do we want to take on A) 3 active development branches and B) 2 active refactoring branches. I will note that I don't believe there is a full set of GTK3 libs available for win32 yet and have no idea about the status on OSX.
Cheers, Josh
P.S. Tavmjong, I cc-ed you explicitly because you didn't put the time we ended up with as available. Any chance it can be made to work?
That's 9 AM Saturday morning here. I can follow the conversation but may not always be available to respond. I've got two young energetic girls that need to be watched while their mother catches up on her sleep...
Will you send out an agenda before the meeting? I think having an agenda really helps in making good use of the time. Things I would like to see discussed are GSOC and a strategy for incorporating SVG2 and other new items (there will be some new things relevant to SVG coming before SVG2 as separate specifications like CSS3 transforms, CSS3 color, etc.).
Tav
On Sat, Feb 11, 2012 at 11:43 AM, Tavmjong Bah <tavmjong@...8...> wrote:
That's 9 AM Saturday morning here. I can follow the conversation but may not always be available to respond. I've got two young energetic girls that need to be watched while their mother catches up on her sleep...
Fair enough.
Will you send out an agenda before the meeting? I think having an agenda really helps in making good use of the time. Things I would like to see discussed are GSOC and a strategy for incorporating SVG2 and other new items (there will be some new things relevant to SVG coming before SVG2 as separate specifications like CSS3 transforms, CSS3 color, etc.).
Sure, I will put together a draft agenda in the next week and send it to the list for people to add to, then I will send a final one the day before the meeting.
Cheers, Josh
participants (9)
-
Alex Valavanis -
Alexandre Prokoudine -
Jon A. Cruz -
Jon Cruz -
Josh Andler -
Krzysztof Kosiński -
Martin Owens -
Stuart Edwards -
Tavmjong Bah