Hi all, The last few days I added functionality to spinboxes: you can now type simple math expressions, like 100+20, 55*2, these kind of things. The code to add this functionality was taken from Gimp, very nice! You can try it out in the transform dialog for example. Works also in the toolbar, but... see below.
It also works with units. You can write things like "2 cm", and it will be converted to whatever unit you have selected. Or you can write "(2 * 2 cm)*5 + 3 in".
Toolbar spinboxes also have this functionality, but lack the unit stuff. (where it would be really convenient :( I will not work on this unit functionality in the toolbar. Maybe someone else can work on C++-ifying the "ege action" stuff and widget/toolbar.cpp, a first step on the way to getting there. In all C++ UI stuff it is easy to add, and let me know if it is missing somewhere.
Ciao, Johan
On Fri, Apr 15, 2011 at 1:56 PM, Johan Engelen <jbc.engelen@...2592...>wrote:
Toolbar spinboxes also have this functionality, but lack the unit stuff. (where it would be really convenient :( I will not work on this unit functionality in the toolbar. Maybe someone else can work on C++-ifying the "ege action" stuff and widget/toolbar.cpp, a first step on the way to getting there. In all C++ UI stuff it is easy to add, and let me know if it is missing somewhere.
Woohoo! You rock!
In very quick testing, It doesn't work in the spinboxes in the Fill & Stroke Dialog and the few Extensions I tried either. Would it be difficult to add the functionality to numeric comboboxes too?
Cheers, Josh
On Fri, Apr 15, 2011 at 2:16 PM, Josh Andler <scislac@...400...> wrote:
On Fri, Apr 15, 2011 at 1:56 PM, Johan Engelen <jbc.engelen@...2592...
wrote:
Toolbar spinboxes also have this functionality, but lack the unit stuff. (where it would be really convenient :( I will not work on this unit functionality in the toolbar. Maybe someone else can work on C++-ifying the "ege action" stuff and widget/toolbar.cpp, a first step on the way to getting there. In all C++ UI stuff it is easy to add, and let me know if it is missing somewhere.
In very quick testing
I spent more time looking into this. So, here's my more "exhaustive" list.
Spinbutton math doesn't work: Preferences>Interface>Zoom correction factor spinbox Object>Fill & Stroke (all spinboxes) Object>Rows and Columns (all spinboxes) Text>SVG Font Editor Extensions (the ones I tested) Filters (any customizable filters, presumably because they're just extensions)
Another "polish" observation (since we were talking about this topic recently): Preferences>Steps has px hardcoded as opposed to configurable units (I could definitely see this being configurable as a very useful feature for technical drawing)
Cheers, Josh
On 16-4-2011 4:18, Josh Andler wrote:
On Fri, Apr 15, 2011 at 2:16 PM, Josh Andler <scislac@...400... mailto:scislac@...400...> wrote:
On Fri, Apr 15, 2011 at 1:56 PM, Johan Engelen <jbc.engelen@...2592... <mailto:jbc.engelen@...2592...>> wrote: Toolbar spinboxes also have this functionality, but lack the unit stuff. (where it would be really convenient :( I will not work on this unit functionality in the toolbar. Maybe someone else can work on C++-ifying the "ege action" stuff and widget/toolbar.cpp, a first step on the way to getting there. In all C++ UI stuff it is easy to add, and let me know if it is missing somewhere. In very quick testingI spent more time looking into this. So, here's my more "exhaustive" list.
Spinbutton math doesn't work: Preferences>Interface>Zoom correction factor spinbox Object>Fill & Stroke (all spinboxes) Object>Rows and Columns (all spinboxes) Text>SVG Font Editor Extensions (the ones I tested) Filters (any customizable filters, presumably because they're just extensions)
Done! "Gtk::SpinButton" is mostly purged from the codebase. (rows and columns top two spinboxes don't work yet. don't know why and, frankly, not going to work on it if you don't mind ;)
Another "polish" observation (since we were talking about this topic recently): Preferences>Steps has px hardcoded as opposed to configurable units (I could definitely see this being configurable as a very useful feature for technical drawing)
Hmmm, interesting!
Ciao, Johan
On 16-4-2011 4:18, Josh Andler wrote:
On Fri, Apr 15, 2011 at 2:16 PM, Josh Andler <scislac@...400... mailto:scislac@...400...> wrote:
Another "polish" observation (since we were talking about this topic recently): Preferences>Steps has px hardcoded as opposed to configurable units (I could definitely see this being configurable as a very useful feature for technical drawing)
Done!
-Johan
On Sun, Apr 17, 2011 at 5:53 AM, Johan Engelen <jbc.engelen@...2592...>wrote:
On 16-4-2011 4:18, Josh Andler wrote:
On Fri, Apr 15, 2011 at 2:16 PM, Josh Andler <scislac@...400...> wrote:
Another "polish" observation (since we were talking about this topic recently): Preferences>Steps has px hardcoded as opposed to configurable units (I could definitely see this being configurable as a very useful feature for technical drawing)
Done!
You rock!!!!!!!!!!! If you keep rocking this hard you may throw the earth off it's axis. ;)
Cheers, Josh
On Apr 15, 2011, at 1:56 PM, Johan Engelen wrote:
Toolbar spinboxes also have this functionality, but lack the unit stuff. (where it would be really convenient :( I will not work on this unit functionality in the toolbar. Maybe someone else can work on C++-ifying the "ege action" stuff and widget/toolbar.cpp, a first step on the way to getting there. In all C++ UI stuff it is easy to add, and let me know if it is missing somewhere.
We have a problem there.
First you did change 10168 which was commented as "remove ridiculous comment"
Unfortunately that was not a ridiculous comment. It was there for a reason. Some parts of our codebase are meant to stay C instead of C++, such as our copies of libraries, code to be shared with non-C++ projects, etc. (when you hit such an item, you can look at the detailed history of the file to see who added it and ask, etc.)
There are also some portions that are plain C++ and not Gtkmm. Those make it easier to share things with other projects, especially Qt/KDE based ones such as Scribus.
Additionally, more than just being C, we have some very tricky issues with Gtkmm vs plain GTK+, and many things work only halfway if implemented with the wrong language. So there are some big picture issues to consider.
On 16-4-2011 8:46, Jon Cruz wrote:
On Apr 15, 2011, at 1:56 PM, Johan Engelen wrote:
Toolbar spinboxes also have this functionality, but lack the unit stuff. (where it would be really convenient :( I will not work on this unit functionality in the toolbar. Maybe someone else can work on C++-ifying the "ege action" stuff and widget/toolbar.cpp, a first step on the way to getting there. In all C++ UI stuff it is easy to add, and let me know if it is missing somewhere.
We have a problem there.
First you did change 10168 which was commented as "remove ridiculous comment"
Unfortunately that was not a ridiculous comment. It was there for a reason. Some parts of our codebase are meant to stay C instead of C++, such as our copies of libraries, code to be shared with non-C++ projects, etc. (when you hit such an item, you can look at the detailed history of the file to see who added it and ask, etc.)
There are also some portions that are plain C++ and not Gtkmm. Those make it easier to share things with other projects, especially Qt/KDE based ones such as Scribus.
Additionally, more than just being C, we have some very tricky issues with Gtkmm vs plain GTK+, and many things work only halfway if implemented with the wrong language. So there are some big picture issues to consider.
I stick to the commit message of r10168.
The C code is very verbose, difficult to read, and no fun to maintain. Especially subclassing is terrible in C-style, and I guess this is why there is so much duplicate code to be found in the UI: nobody can re-use widgets from other parts.
In all C++ dialogs/widgets it is easy to add the extra functionality, and I will do it. In all C code, I will not.
Ciao, Johan
On Apr 16, 2011, at 6:04 AM, Johan Engelen wrote:
I stick to the commit message of r10168.
The C code is very verbose, difficult to read, and no fun to maintain. Especially subclassing is terrible in C-style, and I guess this is why there is so much duplicate code to be found in the UI: nobody can re-use widgets from other parts.
In all C++ dialogs/widgets it is easy to add the extra functionality, and I will do it. In all C code, I will not.
Yes, but the big problem is that you are looking at *shared* code, not Inkscape-only code.
There are actually many other ways to get things in there, with the design such that an ege action can be set to create widgets of other types... so the ege code does not need to be changed, just told which class to use.
This also uses GTK+ directly, which is our main toolkit.
Also the main reason for duplicate code is not inability to subclass, but lack of understanding by many implementing things. Too much is just copied and pasted instead of subclassed, etc. As Krzysztof noted looking into the GSoC C++-ification project, much of the code being changed was extremely similar in C++ as in C, with mainly the long function names being changed to class::member declarations, etc.
Also keep in mind that we have several different things going on here:
* C code * GTK+ C code * C++ code * GtkMM code
And all are different.
But again, the bottom line is that when you changed the C files that were commented as needing to be in C, you broke shared code that was being used in other projects and that will need to be reverted. And there is a proper way to tell that C code to use your C++ widgets so that you don't have to worry about mucking with 'no fun' C code at all.
On Sat, Apr 16, 2011 at 9:17 AM, Jon Cruz <jon@...18...> wrote:
Yes, but the big problem is that you are looking at *shared* code, not Inkscape-only code.
Shouldn't this be documented somewhere such as the wiki? Intending code to be shared vs other projects actually using it is also a different thing.
There are actually many other ways to get things in there, with the design
such that an ege action can be set to create widgets of other types... so the ege code does not need to be changed, just told which class to use.
This also uses GTK+ directly, which is our main toolkit.
Wasn't one of the goals to change to gtkmm for everything? I seem to recall bryce and derek (jizzbug) working on the gtkmmification years ago. I don't recall their goal being partial gtkmmification and I don't recall any opposition to their work.
Also keep in mind that we have several different things going on here:
- C code
- GTK+ C code
- C++ code
- GtkMM code
And all are different.
This really needs to have documentation somewhere. This is the first mention I've seen about that we *want* C and GTK+ C in the codebase. We need to know what's used where and why (even if it's "we haven't gotten around to changing that yet") as well as what should be used where and why.
Cheers, Josh
On Apr 16, 2011, at 10:06 AM, Josh Andler wrote:
This really needs to have documentation somewhere. This is the first mention I've seen about that we *want* C and GTK+ C in the codebase. We need to know what's used where and why (even if it's "we haven't gotten around to changing that yet") as well as what should be used where and why.
Yes, we need to have this documented. The wiki is one place to get things, but most others aren't contributing there so it's a less useful location.
I *thought* the practice of first calling it out in the source file itself would be noticed by other programmers a little more. I guess I made the bad assumption that since they read it they might actually pause to consider and ask why.
But overall working out a map of our source code and some of it's modules is one thing I've been making progress on.
On Apr 17, 2011, at 1:27 PM, inkscape-devel.neophyte_rep@...2295... wrote:
On Sat, Apr 16, 2011 at 6:12 PM, Jon Cruz - jon@...18... wrote:
But overall working out a map of our source code and some of it's modules is one thing I've been making progress on.
You intend to publish this map somewhere, right?
Yes...
but aside from a few other issues I keep getting sidetracked with having to un-break code (some of it repeatedly). My current main one is to get the absolute/relative path issue. Given some recent contributions in that area, we have some people interested in helping test there so I'm trying to get that fixed again while they're still around.
On 16-4-2011 18:17, Jon Cruz wrote:
On Apr 16, 2011, at 6:04 AM, Johan Engelen wrote:
I stick to the commit message of r10168.
The C code is very verbose, difficult to read, and no fun to maintain. Especially subclassing is terrible in C-style, and I guess this is why there is so much duplicate code to be found in the UI: nobody can re-use widgets from other parts.
In all C++ dialogs/widgets it is easy to add the extra functionality, and I will do it. In all C code, I will not.
Yes, but the big problem is that you are looking at *shared* code, not Inkscape-only code.
Shared with which other projects? It is nice that we benefit by this sharing, and as such, I see that the code is updated very regularly from improvements by the other sharing projects.
There are actually many other ways to get things in there, with the design such that an ege action can be set to create widgets of other types... so the ege code does not need to be changed, just told which class to use.
Didn't my commit just do that? "tell it to use another class" ?
This also uses GTK+ directly, which is our main toolkit.
Sorry, I do not understand what you meant by that comment.
Also the main reason for duplicate code is not inability to subclass, but lack of understanding by many implementing things. Too much is just copied and pasted instead of subclassed, etc.
Exactly what I meant: subclassing is not done, maybe because it is a pain in C-style.
As Krzysztof noted looking into the GSoC C++-ification project, much of the code being changed was extremely similar in C++ as in C, with mainly the long function names being changed to class::member declarations, etc.
I think Krzysztof's comments about the GSoC C++-ification were meant as a disappointment (which I share). C++-ification does not mean changing functions to class::member stuff. It means, for example, getting rid of elaborate code to get polymorphism and virtual functions in C-style, by using C++ classes and virtual functions.
Also keep in mind that we have several different things going on here:
- C code
- GTK+ C code
- C++ code
- GtkMM code
And all are different.
But again, the bottom line is that when you changed the C files that were commented as needing to be in C, you broke shared code that was being used in other projects and that will need to be reverted. And there is a proper way to tell that C code to use your C++ widgets so that you don't have to worry about mucking with 'no fun' C code at all.
I suppose the added functionality in Inkscape is not worth "breaking" the "sharing of code" that changes approximately once every year. Upon reverting, please add your arguments to the 5+ wishlist reports on Launchpad for math expression support in input fields, and mark them as "won't fix".
-Johan
On Apr 16, 2011, at 12:58 PM, Johan Engelen wrote:
On 16-4-2011 18:17, Jon Cruz wrote:
On Apr 16, 2011, at 6:04 AM, Johan Engelen wrote:
I stick to the commit message of r10168.
The C code is very verbose, difficult to read, and no fun to maintain. Especially subclassing is terrible in C-style, and I guess this is why there is so much duplicate code to be found in the UI: nobody can re-use widgets from other parts.
In all C++ dialogs/widgets it is easy to add the extra functionality, and I will do it. In all C code, I will not.
Yes, but the big problem is that you are looking at *shared* code, not Inkscape-only code.
Shared with which other projects? It is nice that we benefit by this sharing, and as such, I see that the code is updated very regularly from improvements by the other sharing projects.
Yes, it is. Since it is mainly from other projects I have going.
Thanks for the kudos.
As Krzysztof noted looking into the GSoC C++-ification project, much of the code being changed was extremely similar in C++ as in C, with mainly the long function names being changed to class::member declarations, etc.
I think Krzysztof's comments about the GSoC C++-ification were meant as a disappointment (which I share). C++-ification does not mean changing functions to class::member stuff. It means, for example, getting rid of elaborate code to get polymorphism and virtual functions in C-style, by using C++ classes and virtual functions.
Some, but not all. However *MORE* important is getting proper encapsulation and modularity.
Just in doing that we have found many subtle bugs in our code. C-style casts are one of the worst offenders.
I suppose the added functionality in Inkscape is not worth "breaking" the "sharing of code" that changes approximately once every year. Upon reverting, please add your arguments to the 5+ wishlist reports on Launchpad for math expression support in input fields, and mark them as "won't fix".
Sorry for the lack of updates, but nobody has been pointing any of those out to me.
Also, I've been quite busy with several things, including helping out a friend who's funeral and memorial are taking me away from Inkscape work today. sorry for the inconvenience to you.
participants (4)
-
unknown＠example.com -
Johan Engelen -
Jon Cruz -
Josh Andler