The "Latency skew" and "Pre-render named icons" options make absolutely zero sense for the user.
Especially the former. For the latter, I can at least guess that it's something to do with icons. With "skew", I'm totally at a loss. What latency? Where? When? Tooltip only exacerbates the confusion.
Can we please remove them and never, never again add such "options for the developers" to the UI?
On Jan 31, 2009, at 6:34 PM, bulia byak wrote:
The "Latency skew" and "Pre-render named icons" options make absolutely zero sense for the user.
Especially the former. For the latter, I can at least guess that it's something to do with icons. With "skew", I'm totally at a loss. What latency? Where? When? Tooltip only exacerbates the confusion.
Can we please remove them and never, never again add such "options for the developers" to the UI?
Well, if you skim the archives you should see that it was added to help users, and was for an issue Mental added that you'd complained a lot about.
Also it is directly related to X11 input timing, and with all the recent changes on that front, the issue is pertinent again. I recently spent time discussing things with Peter Hutterer (who did MPX) including the state of X Input and recently released features (was said to be in X as of Jan 1). He also covered in his talk t linux.conf.au that GIMP and maybe Inkscape were the only apps actually using the extra stuff, so it does look like we'll be on the front of things as the updates to X start to show up in users hands.
However, as a general rule I think we definitely need to have a "review the prefs" task that we do whenever things might look like we're closing in on a release.
On Sun, Feb 1, 2009 at 2:26 AM, Jon A. Cruz <jon@...18...> wrote:
Well, if you skim the archives you should see that it was added to help users, and was for an issue Mental added that you'd complained a lot about.
Well, in that case you should have added a link to the archives right into the tooltip :)
Seriously, I don't remember that, and if it is indeed necessary for anything, you should try to write a more understandable explanation in the UI. Right now it does not even mention what lags relative to what, just mentions some "events" (which is meaningless for the user).
2009/2/1 bulia byak <buliabyak@...400...>:
On Sun, Feb 1, 2009 at 2:26 AM, Jon A. Cruz <jon@...18...> wrote:
Well, if you skim the archives you should see that it was added to help users, and was for an issue Mental added that you'd complained a lot about.
Well, in that case you should have added a link to the archives right into the tooltip :)
Seriously, I don't remember that, and if it is indeed necessary for anything, you should try to write a more understandable explanation in the UI. Right now it does not even mention what lags relative to what, just mentions some "events" (which is meaningless for the user).
-- bulia byak
Would it be worth having a tab that can be turned on/off with a pref value (defaulting to off) that lets you set things like this, so we can have developer debugging type preferences that are easily changed but not exposed to all the users?
On Sun, Feb 1, 2009 at 10:07 AM, john cliff <john.cliff@...400...> wrote:
Would it be worth having a tab that can be turned on/off with a pref value (defaulting to off) that lets you set things like this, so we can have developer debugging type preferences that are easily changed but not exposed to all the users?
Probably, but then, if you are going into preferences.xml at all, why not just set up a debug pref right there? We've used this many times and it worked well.
On 02/01/2009 08:42 AM, bulia byak wrote:
On Sun, Feb 1, 2009 at 10:07 AM, john cliff<john.cliff@...400...> wrote:
Would it be worth having a tab that can be turned on/off with a pref value (defaulting to off) that lets you set things like this, so we can have developer debugging type preferences that are easily changed but not exposed to all the users?
Probably, but then, if you are going into preferences.xml at all, why not just set up a debug pref right there? We've used this many times and it worked well.
I think that having a debug/testing tab in preferences would probably be a smart idea in the long run. As for the "already going into preferences.xml" part, this would be a one time action and then all debug prefs could be exposed (including others that people add after the fact... given the ui is added obviously). One use I could think of would be to have a preference for toggling the LPEs that are in testing/experimental, so it's not required to recompile to toggle.
Cheers, Josh
Josh Andler wrote:
I think that having a debug/testing tab in preferences would probably be a smart idea in the long run.
A better idea is to have a tree view that lets you change / add / modify arbitrary preferences, similar to gconf-editor. This should be doable without any changes to the Inkscape::Preferences object.
Regards, Krzysztof Kosiński
On Sun, 2009-02-08 at 19:44 -0800, Krzysztof Kosiński wrote:
Josh Andler wrote:
I think that having a debug/testing tab in preferences would probably be a smart idea in the long run.
A better idea is to have a tree view that lets you change / add / modify arbitrary preferences, similar to gconf-editor. This should be doable without any changes to the Inkscape::Preferences object.
Heh, or maybe just use GConf ;)
--Ted
Ted Gould wrote:
Heh, or maybe just use GConf ;)
There was a discussion earlier about this. I was a big proponent of it. In fact it was one of the reasons I refactored prefs handling into a single object and kept the XML implementation details of Inkscape::Preferences inaccessible from its public interface. We decided against it because it would cause Inkscape to have two sets of preferences for people who use both KDE and Gnome (in Gnome it would use GConf, but in KDE it would fall back to a different set of preferences from the XML file). If you can come up with a good idea how to handle this case, we might reconsider it.
Regards, Krzysztof Kosiński.
On Feb 18, 2009, at 3:17 AM, Krzysztof Kosiński wrote:
Ted Gould wrote:
Heh, or maybe just use GConf ;)
There was a discussion earlier about this. I was a big proponent of it. In fact it was one of the reasons I refactored prefs handling into a single object and kept the XML implementation details of Inkscape::Preferences inaccessible from its public interface. We decided against it because it would cause Inkscape to have two sets of preferences for people who use both KDE and Gnome (in Gnome it would use GConf, but in KDE it would fall back to a different set of preferences from the XML file). If you can come up with a good idea how to handle this case, we might reconsider it.
There are a few issues with things, but I think the main thing we're seeing now is lack of modularity.
I'll have to dig in on some actual design details with various patterns, but off-hand I can describe it that we need to use some adapters and also to switch some things to push instead of poll.
In one sense we can view the preferences as a global variable, which is slightly evil. However, once we change code to have its values pushed in, instead of having each little sub-bit of code poll the preferences thing, then we can switch even more easily.
Another issue we have that is showing some problem with this is the toolbars.
I think one pattern I've heard used is "dependency injection". Many aspects of that address what we're seeing in the code now.
Jon A. Cruz wrote:
In one sense we can view the preferences as a global variable, which is slightly evil. However, once we change code to have its values pushed in, instead of having each little sub-bit of code poll the preferences thing, then we can switch even more easily.
The preferences being global is not a bad thing, since we want consistent behavior. There is exactly zero use for multiple Preferences objects. Similarly, using the "global" clipboard is not bad. I think you're taking the "globals are evil" approach too far.
The only problem with the prefs now is that nearly everything depends on them, so it's hard to come up with the correct link order and it would be hard to separate out libraries to use for other apps. However, the first point would be mooted if we linked the executable from single object files rather than a multitude of static libraries, because then the linker would resolve back-references and the link order wouldn't matter.
I think one pattern I've heard used is "dependency injection". Many aspects of that address what we're seeing in the code now.
This is essentially what I wanted to do when I proposed GConf.
Regards, Krzysztof Kosiński
On Feb 19, 2009, at 4:11 PM, Krzysztof Kosiński wrote:
The preferences being global is not a bad thing, since we want consistent behavior. There is exactly zero use for multiple Preferences objects. Similarly, using the "global" clipboard is not bad. I think you're taking the "globals are evil" approach too far.
The only problem with the prefs now is that nearly everything depends on them, so it's hard to come up with the correct link order and it would be hard to separate out libraries to use for other apps. However, the first point would be mooted if we linked the executable from single object files rather than a multitude of static libraries, because then the linker would resolve back-references and the link order wouldn't matter.
...
I think one pattern I've heard used is "dependency injection". Many aspects of that address what we're seeing in the code now.
This is essentially what I wanted to do when I proposed GConf.
That's not what I'm seeing.
I'll try to draw a lot up to pinpoint the differences, but a key is that things are spaghetti connected when what we need are stand-alone sub-components that can be reused in different ways. A few of the patterns that might come into play could include mediator, memento, and adapter.
A color picker is a good example. If the color picker class itself hooked into the preferences, we would not be able to reuse it within different contexts. However if the color picker only picks a color and exposes a property or two, then different classes could create their own instances of color pickers, with some colors getting their values shoved in from preference settings, but others not. An adapter could be hooked to one color picker to keep it in sync with a specific preference setting, but then another color picker might be connected to a context object that switches to track the active documents.
In that case instead of having a color picker poll the preferences directly, the color picker would only know UI for selecting a color. Then a different small class would be instantiated that knows about preferences and about color pickers, and would watch the color picker's property and push any changes into the preferences. It could also watch the preference for changes and push those into the color picker as needed.
Among other things, by separating responsibilities we get pieces of code that can be more easily reused and also can be easily tested. Without such separation it becomes significantly more difficult to engage in a Test Driven Development (TDD) approach.
One of the concrete instances of such abstract problems was encountered in the toolbars and drawing contexts. I have to do some more cleanup on the eraser context, as there is still a fair bit of duplicate code in need of refactoring, but I did run up on some major problems. The worse is that the existing context was not reusable. It depended on the UI widgets such as sliders to actually set default values to get things functional. It also counted on the widgets for range checking, instead of validating values itself. That also caused problems with trying to make the UI dynamic and toolbars configurable.
participants (6)
-
bulia byak -
john cliff -
Jon A. Cruz -
Josh Andler -
Krzysztof Kosiński -
Ted Gould