Hi all,
Recently I've been appraising how much work it's going to take to achieve the goal we set for 0.42 to get converted to gtkmm.
The choice to switch to gtkmm was made at the very start of the project, so it's always been one of our biggest goals. Several actions we took in our earlier releases were geared towards this end. In fact, we've been planning to convert to gtkmm for several releases now.
Of course, this is not a trivial undertaking. Initially we approached doing it piecemeal, one dialog at a time. Several dialogs got converted, but we noticed that each dialog turned out surprisingly different than the others. This is where I got involved - to try to help establish some common practices for implementing dialogs. I also figured that even though I had other stuff I wanted to work on (i.e. markers and extensions), for project priorities it was probably more valuable to pitch in with getting progress on the gtkmm stuff.
Today I think the new dialog code is pretty good. There is a base class we can use for dialogs, that provides the common behaviors, and a DialogManager to better track their memory and instantiation. The individual dialogs still need to all be converted over, but we've already got a handful converted, and there's another handful that are already in gtkmm but just need to be restyled to work with the new code. So now, the rest of the dialog conversion work *can* be done piece by piece, without risking problematic inconsistencies.
However, converting to gtkmm means much more than just converting each dialog; the main interface (toolbars, buttons, canvas, etc.) also needs to be turned into gtkmm code. This requires conversion of SPView, SPSvgView, SPDesktop, and SPDesktopView. SPDesktop alone is a pretty big project; I've been hammering at it bit by bit for the past few months but feel like I've barely made a dent. It's pretty frustrating; I feel like I'm pulling the proverbial thread from the sweater.
Anyway, given what it looks like needs to be done, I don't really have the time/patience/energy to see the View/Desktop work through to completion by myself. There are other things I want to do for Inkscape and Open Clip Art that are higher priority to me. If someone else wants to work on it, I can share what I've learned and explain what it looks like needs to be done.
Finally, given this, I see no point in continuing with the goal of completing gtkmm for 0.42. It's just too much effort, compared with the number of people committed to working on it. I hate the idea of having to yet again bump it to the next release, though. If it couldn't be achieved for 0.39, 0.40, 0.41, and 0.42, why would we think it could be done for 0.43? I think that given the lack of activity, the most logical thing is to just postpone it indefinitely. The work just seems to get in the way of making releases, and given that people are more interested in working on misc. individual things rather than gtkmm, anyway, there's little value in setting it as a goal; it just sets up expectations that are proving unachievable. The desire for a release is clearly much higher than the desire to finish implementing gtkmm at this time.
Thus, I would like to propose we scrap the remaining plans for 0.42 in the roadmap, and go ahead and start the 0.42 release process.
Opinions?
Bryce
On Sun, 2005-05-08 at 13:33 -0700, Bryce Harrington wrote:
Hi all,
Recently I've been appraising how much work it's going to take to achieve the goal we set for 0.42 to get converted to gtkmm.
The choice to switch to gtkmm was made at the very start of the project, so it's always been one of our biggest goals. Several actions we took in our earlier releases were geared towards this end. In fact, we've been planning to convert to gtkmm for several releases now.
And its a great goal...
Of course, this is not a trivial undertaking. Initially we approached doing it piecemeal, one dialog at a time. Several dialogs got converted, but we noticed that each dialog turned out surprisingly different than the others. This is where I got involved - to try to help establish some common practices for implementing dialogs. I also figured that even though I had other stuff I wanted to work on (i.e. markers and extensions), for project priorities it was probably more valuable to pitch in with getting progress on the gtkmm stuff.
Today I think the new dialog code is pretty good. There is a base class we can use for dialogs, that provides the common behaviors, and a DialogManager to better track their memory and instantiation. The individual dialogs still need to all be converted over, but we've already got a handful converted, and there's another handful that are already in gtkmm but just need to be restyled to work with the new code. So now, the rest of the dialog conversion work *can* be done piece by piece, without risking problematic inconsistencies.
Did you use my new generic map structure implementation for managing dialogs??? I would like to get that in place soon... ;)
However, converting to gtkmm means much more than just converting each dialog; the main interface (toolbars, buttons, canvas, etc.) also needs to be turned into gtkmm code. This requires conversion of SPView, SPSvgView, SPDesktop, and SPDesktopView. SPDesktop alone is a pretty big project; I've been hammering at it bit by bit for the past few months but feel like I've barely made a dent. It's pretty frustrating; I feel like I'm pulling the proverbial thread from the sweater.
Anyway, given what it looks like needs to be done, I don't really have the time/patience/energy to see the View/Desktop work through to completion by myself. There are other things I want to do for Inkscape and Open Clip Art that are higher priority to me. If someone else wants to work on it, I can share what I've learned and explain what it looks like needs to be done.
Finally, given this, I see no point in continuing with the goal of completing gtkmm for 0.42. It's just too much effort, compared with the number of people committed to working on it. I hate the idea of having to yet again bump it to the next release, though. If it couldn't be achieved for 0.39, 0.40, 0.41, and 0.42, why would we think it could be done for 0.43? I think that given the lack of activity, the most logical thing is to just postpone it indefinitely. The work just seems to get in the way of making releases, and given that people are more interested in working on misc. individual things rather than gtkmm, anyway, there's little value in setting it as a goal; it just sets up expectations that are proving unachievable. The desire for a release is clearly much higher than the desire to finish implementing gtkmm at this time.
I think that slow refactoring is key, but more importantly we decided that no more of the interface will be coded in GTK+, but gtkmm. I think if we decided this much much more will happen. Maybe it is not so realistic to force conversion from the pure top down effort, but if we set some simple rules, like WE NOW PREFER GTKMM, I think we will reach our goal quicker.
Thus, I would like to propose we scrap the remaining plans for 0.42 in the roadmap, and go ahead and start the 0.42 release process.
Opinions?
I think the sooner the better. I feel the attn. span slowing on Inkscape, which is okay, but I think better to stay in the news and to keep feeding users new features, rather than keep them with the old copy of Inkscape...our quicker releases is one of our advantages...
Jon
On Mon, May 09, 2005 at 07:05:47PM -0700, Jon Phillips wrote:
On Sun, 2005-05-08 at 13:33 -0700, Bryce Harrington wrote:
Today I think the new dialog code is pretty good. There is a base class we can use for dialogs, that provides the common behaviors, and a DialogManager to better track their memory and instantiation. The individual dialogs still need to all be converted over, but we've already got a handful converted, and there's another handful that are already in gtkmm but just need to be restyled to work with the new code. So now, the rest of the dialog conversion work *can* be done piece by piece, without risking problematic inconsistencies.
Did you use my new generic map structure implementation for managing dialogs??? I would like to get that in place soon... ;)
In fact yes, I did have fun playing with that! :-)
I made a few tweaks to the code. First, instead of making it a hash map of strings to Dialogs, it now uses a map of GQuarks to Dialogs. That should be somewhat more efficient. Also, I added GQuark versions of the add, remove, etc. routines.
There's just one more feature that must be added before we can rip out the current code and go entirely with your generic map structure.
You'll notice that in the current code, the functions are like this:
Dialog* DialogManager::getExportDialog() { if (_export_dialog == NULL) { _export_dialog = new Export; hide_dialogs.connect(sigc::mem_fun(*_export_dialog, &Export::onHideDialogs)); hide_f12.connect(sigc::mem_fun(*_export_dialog, &Export::onHideF12)); show_dialogs.connect(sigc::mem_fun(*_export_dialog, &Export::onShowDialogs)); show_f12.connect(sigc::mem_fun(*_export_dialog, &Export::onShowF12)); } return _export_dialog; }
Each of the dialogs has one function like that. The function basically looks to see if the export dialog has been instantiated, instantiates it if needed, and returns it. The fact that it auto-instantiates when called is very nice because a) it allows the caller to assume the dialog will always exist under normal circumstances, and b) it allows us to be lazy about instantiating it until the dialog is actually needed.
Anyway, we want to replace all this with your handy dandy genericized function:
Dialog* DialogManager::getDialog(GQuark q) { DialogMap::const_iterator iter = _dialog_map.find(q); if (iter != _dialog_map.end()) { return (*iter).second; // dialog found } else { return NULL; // dialog not found } }
However, you can see that in the case of a dialog not found, it doesn't instantiate it for us nicely, but instead returns NULL.
A good technique for providing this capability is to implement Factory methods (see a Design Patterns book for detail).
This probably means we will need to have each dialog include a create() function that returns a new'd Dialog* of its class, and then build a hash of GQuarks to create() function pointers. We would then also need a registration function to add new create() functions to the hash.
Once these things exist, we can eliminate all the existing get*Dialog() routines and go with your code exclusively.
I think that slow refactoring is key, but more importantly we decided that no more of the interface will be coded in GTK+, but gtkmm. I think if we decided this much much more will happen. Maybe it is not so realistic to force conversion from the pure top down effort, but if we set some simple rules, like WE NOW PREFER GTKMM, I think we will reach our goal quicker.
Yeah, I talked with mental about this and think it's correct that a slow refactoring is a more viable approach, even though it seems to take forever to get through. ;-) I think this is especially true for the view/desktop code.
Thus, I would like to propose we scrap the remaining plans for 0.42 in the roadmap, and go ahead and start the 0.42 release process.
Opinions?
I think the sooner the better. I feel the attn. span slowing on Inkscape, which is okay, but I think better to stay in the news and to keep feeding users new features, rather than keep them with the old copy of Inkscape...our quicker releases is one of our advantages...
Yup, my thoughts too.
Bryce
I've uploaded the German language versions, sorry for the dupe.
Others?
ralf
The issue of removing trailing spaces from the source: I don't think you want my 1MB patch, you want this script:
for i in `find . -name '*.h'` do sed 's/ *$//g' <$i >t mv t $i done
for i in `find . -name '*.c'` do sed 's/ *$//g' <$i >t mv t $i done
for i in `find . -name '*.cpp'` do sed 's/ *$//g' <$i >t mv t $i done
Please apply from src/
I'm off, ralf
Quoting Bryce Harrington <bryce@...260...>:
A good technique for providing this capability is to implement Factory methods (see a Design Patterns book for detail).
This probably means we will need to have each dialog include a create() function that returns a new'd Dialog* of its class, and then build a hash of GQuarks to create() function pointers. We would then also need a registration function to add new create() functions to the hash.
And this is where I think it veers a bit off course.
I'll have to get up to speed on the overal state of things, but requiring a create() function on the dialog classes might be restrictive. Instead we might want to have a collection of Factories there, and let them have a create() method. Then the DialogManager would be a Facade in front of the Factories (and maybe even multiple inheritance could be used to have create() on some dialog classes themselves).
However... the big picture is what we might need to look at here. In this case, we're getting tripped up by tricky implementation details, but if it's for something we don't need to be doing in the first place, then we can avoid a lot of the complexity and trickiness.
The thing that trips my radar is the getDialog() method. Instead of jumping straight down into "how can we code this method", let's back up and say "*why* are we coding this method?" That in general, and in this case specifically, can lead to clarity and reduction of problems.
:-)
So... one question is "why do other parts of the code *need* to get a dialog?" Do they really care that much about the details of how some UI is being presented? If not, then I say we should get rid of that method altogether.
This is where adding a "PanelManager" or some such might come in. If the code that's making that other call really only needs to be able to present a given 'control panel' thingie, and doesn't need to know if it's in a dialog or embedded in the UI elsewhere, then don't ask for a 'dialog'. Is the end goal more like "Show the user the thing so that he can align and distribute"? If so, then we can have
FooManager::showPanel(GQuark q) {...}
Then the using code would no longer need to duplicate the functionality of asking for a given dialog and then showing it. So duplicate code would be refactored out to a common function. Additionally, in the cases where no Dialog itself were involved, the using code would neither know or care, and things would just work. And... if using dialogs or not were to be changed in any given cases, changes would be limited and kept away from the other parts of the code that were calling it.
In essence, I'm not suggesting trashing the existing stuff as much as A) adding a layer of abstraction and B) shifting our focus away from presentation and onto information.
BTW, once I had this stuff worked out in general conceptually, I went and checked what the latest GIMP does. And it turns out that functionally it lines up to be presenting the same concpets, including just flashing the title bar of an embedded panel if the requested "dialog" is docked.
On Tue, May 10, 2005 at 12:33:13PM -0400, jon@...18... wrote:
Quoting Bryce Harrington <bryce@...260...>:
A good technique for providing this capability is to implement Factory methods (see a Design Patterns book for detail).
This probably means we will need to have each dialog include a create() function that returns a new'd Dialog* of its class, and then build a hash of GQuarks to create() function pointers. We would then also need a registration function to add new create() functions to the hash.
And this is where I think it veers a bit off course.
I'll have to get up to speed on the overal state of things, but requiring a create() function on the dialog classes might be restrictive. Instead we might want to have a collection of Factories there, and let them have a create() method. Then the DialogManager would be a Facade in front of the Factories (and maybe even multiple inheritance could be used to have create() on some dialog classes themselves).
If you re-read what I wrote, you'll notice you just restarted what I was saying. ;-) So if I've veered off course, you're right there with me. Factory methods, create() routines somewhere, and DialogManager as a front end.
In any case, I offered that implementation approach just as a suggestion. Whomever implements it can do it differently if they wish.
However... the big picture is what we might need to look at here. In this case, we're getting tripped up by tricky implementation details, but if it's for something we don't need to be doing in the first place, then we can avoid a lot of the complexity and trickiness.
I'm sorry that you're getting confused so easily. ;-)
Honestly, this is not that tricky. The mechanisms here are also general enough that you could probably reuse them fairly easily for panels.
I suspect your intolerance for dialogs is getting in your way. I think instead of jumping up and down whenever someone mentions the word 'dialog' you should try to understand what is being worked on and how it can be adapted to be used for panels.
The thing that trips my radar is the getDialog() method. Instead of jumping straight down into "how can we code this method", let's back up and say "*why* are we coding this method?" That in general, and in this case specifically, can lead to clarity and reduction of problems.
:-)
So... one question is "why do other parts of the code *need* to get a dialog?" Do they really care that much about the details of how some UI is being presented? If not, then I say we should get rid of that method altogether.
I know that the point you've been trying to make is that instead of getDialog, you want to see something that does a get-dialog-or-panel.
But consider this: The work of modifying DialogManager into a PanelManager is trivial compared with the work of implementing the logic for doing panels, coordinating whether to show a dialog or a panel, adapting the GUI framework to allow fitting panels in, etc. etc. You're trying to wag the dog by the tail. ;-)
Don't worry about the DialogManager/PanelManager stuff. That is going to be the EASY part. Get the panels themselves working, and the code for letting the user select whether to do it as a dialog or a panel, first.
And I'll assert that were we to try to alter the DialogManager design right now to fit in a panel notion, to "save time", it won't. We don't know what the panel system looks like so would only be making guesses; chances are we'd have to reimplement it anyway. Better to keep DialogManager simple now, and wait on refactoring it until we know how it will need to be changed to handle panels.
I have been thinking of your panel idea for a while, and the way we're adapting DialogManager to generalize its functions moves it in a direction that will be suitable for managing panels as well. It will take more work to complete it, but I don't think it's worth worrying about until the panels are further along.
From the dialog side of things, there is still a lot of work to do to
clean things up. There are many Gtk+ dialogs that need converted, other gtkmm dialogs that need to be brought into the manager, etc. The work to square these things up and unify implementation at the dialog level will make it easier to convert them to panels later. So I think it would be better for you to _encourage_ this work rather than rant "die die die". ;-)
Then the using code would no longer need to duplicate the functionality of asking for a given dialog and then showing it. So duplicate code would be refactored out to a common function. Additionally, in the cases where no Dialog itself were involved, the using code would neither know or care, and things would just work. And... if using dialogs or not were to be changed in any given cases, changes would be limited and kept away from the other parts of the code that were calling it.
Okay, now you're veering off course. ;-)
I don't think you understand what the goal here is. You're not incorrect that we want a common function for showing a dialog, however the real objective is to generalize.
Currently, in verbs.cpp you see switches like this:
switch (reinterpret_caststd::size_t(data)) { case SP_VERB_DIALOG_DISPLAY: sp_display_dialog (); break; case SP_VERB_DIALOG_NAMEDVIEW: sp_desktop_dialog (); break;
Your suggestion would be to simply replace sp_desktop_dialog() with something like, dlg_mgr->showDisplay().
The problem with this, though, is that it leaves the dialog identity hardcoded in verbs. What I would like to do is eliminate the switch entirely, and encapsulate it entirely within DialogManager:
dlg_mgr->showDialog(reinterpret_caststd::size_t(data));
This means that the showDialog() calss would need to translate the 'SP_VERB_DIALOG_DISPLAY' into the appropriate GQuark, use getDialog() to retrieve the corresponding dialog, and show it. It's not clear how to do the 'translate' part yet, though, so we've not bothered trying to create that common function. However, we can kind of morph the switch statement in verbs.cpp in that direction for now.
Of course, in all of the above, s/dialog/panel/i if you prefer. Exactly the same situation.
In essence, I'm not suggesting trashing the existing stuff as much as A) adding a layer of abstraction and B) shifting our focus away from presentation and onto information.
Well, feel free to patch. ;-) Myself, though, I think you need to get the panel stuff functioning before it's worth worrying about abstracting DialogManager and stuff. Adapting all of this to do panels seems pretty minor in comparison, so doesn't seem worth worrying about yet. Also, I think getting the transient and preferences stuff working is higher priority for DialogManager than implementing panel support.
Bryce
Bryce Harrington wrote:
If you re-read what I wrote, you'll notice you just restarted what I was saying. ;-) So if I've veered off course, you're right there with me. Factory methods, create() routines somewhere, and DialogManager as a front end.
Actually, I did read it, and understood it fairly well.
The problem is that I'm viewing things with a slightly different skew. I'm afraid that in order to convey things best I'll probably have to just code things up, but then again that's a good thing code-wise. Being tied up with work kept me from looking at things sooner, but now I should have enough time to at least be able to anylize things better.
In any case, I offered that implementation approach just as a suggestion. Whomever implements it can do it differently if they wish.
Yes. A very key point. All you presented was very good, and quite helpful to people actually looking to implement.
I suspect your intolerance for dialogs is getting in your way. I think instead of jumping up and down whenever someone mentions the word 'dialog' you should try to understand what is being worked on and how it can be adapted to be used for panels.
Well... that is a good thing to suspect and then eliminate. Yes, I am aware of that, but I do believe that it's not really a factor here. It's more a point of trying to separate the information from the presentation. Or to split the model from the view. Etc.
I think much of it can be thought of as trying to separate the abstract concepts in play from the implementation and presentation of those concepts.
The problem with this, though, is that it leaves the dialog identity hardcoded in verbs. What I would like to do is eliminate the switch entirely, and encapsulate it entirely within DialogManager:
dlg_mgr->showDialog(reinterpret_caststd::size_t(data));
This means that the showDialog() calss would need to translate the 'SP_VERB_DIALOG_DISPLAY' into the appropriate GQuark, use getDialog() to retrieve the corresponding dialog, and show it. It's not clear how to do the 'translate' part yet, though, so we've not bothered trying to create that common function. However, we can kind of morph the switch statement in verbs.cpp in that direction for now.
Oh, yes. Getting rid of that hardcoding is a good thing, and also what I was promoting (I was not pushing that other method that you mentioned).
However... in this precise case, do we really *need* to end up showing a dialog? Or can it just flash a border in the UI where that control already is visible?
In one case "showDialog()" can lead to a certain set of expectations, while "showUI()" or some such can help separate the mixed concepts.
The subtle shift in viewing things is much like the difference in coding with the assumption that a byte is a character. Far less work to code it with explicitly separated concepts to begin with than to go in later and try to split them in a refactoring. Initially things might resolve with one byte each in most cases, but the first time you start to run up against cases where a char is more than one byte, ouch.
From the dialog side of things, there is still a lot of work to do to clean things up. There are many Gtk+ dialogs that need converted, other gtkmm dialogs that need to be brought into the manager, etc. The work to square these things up and unify implementation at the dialog level will make it easier to convert them to panels later. So I think it would be better for you to _encourage_ this work rather than rant "die die die". ;-)
Well... could be... But then if the effort is chaning things that will have to be undone later, then it's a bit of 'wandering' effort. Minimizing the ammount of work that will just need to be undone in the immediate future is often a good thing. Leaving work for refactoring is good, but it's easy to cross the point where too much needs to be un-done instead of re-done.
Till now the Dialog stuff has been changing in areas that have been independent from other areas. Now, though, it's a good time to make sure we keep things going in good directions. We are now hitting the area of overlap. I'll try to get it all mapped out well
Also... if some things are cleaned up before dialogs are converted, then we'll end up with a lot fewer lines of code to muck about with. I know much of this seems like pedantic nit-picking, but over many years, with many languages and with many toolkits, I've gained a good feel for things that can slow overall development, and things that can speed it.
On Tue, May 10, 2005 at 07:49:46PM -0700, Jon A. Cruz wrote:
The problem is that I'm viewing things with a slightly different skew. I'm afraid that in order to convey things best I'll probably have to just code things up, but then again that's a good thing code-wise.
Yep, I think that's the right course to take. I think everyone pretty much thinks its a good idea, it's just a matter of coding time.
Oh, yes. Getting rid of that hardcoding is a good thing, and also what I was promoting (I was not pushing that other method that you mentioned).
However... in this precise case, do we really *need* to end up showing a dialog? Or can it just flash a border in the UI where that control already is visible?
Until panels are implemented, yes it needs to end up showing a dialog. When panels are implemented, then it should either show a dialog or panel.
Note that this will need to be configurable, as some users may want to force the panes to always show up as panels, others as dialogs. Also, I can easily imagine someone wishing to have some as panels (heavily used ones), but the rest as dialogs. There's going to be a good bit of logic implemented there to store the preferences and to present the user with an intuitive interface for selecting which to do as dialogs and which to do as panels. Hopefully you've already got ideas in mind for how to do it.
The subtle shift in viewing things is much like the difference in coding with the assumption that a byte is a character. Far less work to code it with explicitly separated concepts to begin with than to go in later and try to split them in a refactoring. Initially things might resolve with one byte each in most cases, but the first time you start to run up against cases where a char is more than one byte, ouch.
DialogManager is all of about 500 lines, and half of those will go away once the generalized functions are finished. This is not very much code that we're talking about, and refactoring later on will not be a very difficult task. My guess is that the work is mostly going to be renaming a few things here and there, and maybe adjusting some calling syntax.
Also, don't dismiss refactoring too readily. Consider that as a general rule, while open source projects can often be weak at documenting, design, etc. they definitely have a big strength in tweaking code. It may seem that it would take less time to create a complete, complex solution from whole cloth, but often it's better to just make something simple that solves *today's* needs, and evolve it to do more, later. For many people, coding is the *fun* part. ;-)
In fact, I had a long discussion with mental regarding refactoring last weekend, as pertains to gtkmm. I've always been a believer in refactoring, but after speaking with him I'm even moreso. Open Source is all about evolution, and works best when the code is active. While I think it was useful for me to work on the gtkmm code separately, it needs to be "in the way" to get enough developer attention / participation. It may seem like it'd be less time to code something from scratch, but as mental pointed out, sometimes when you consider the whole thing end to end, the refactoring approach can be the more efficient way to go.
Till now the Dialog stuff has been changing in areas that have been independent from other areas. Now, though, it's a good time to make sure we keep things going in good directions. We are now hitting the area of overlap. I'll try to get it all mapped out well
Well, dialogs don't overlap with very much. Most dialog headers are only included by a few .cpp's. Pick a dialog header and do a grep -sr.
The same is going to be true for the dialog manager; its header is only needed in a few places, and longer term will be used in even fewer.
The area that will be complicated for panels is the sp-desktop code, but like I mentioned the other day, I decided not to gtkmmify that.
Also... if some things are cleaned up before dialogs are converted, then we'll end up with a lot fewer lines of code to muck about with. I know much of this seems like pedantic nit-picking, but over many years, with many languages and with many toolkits, I've gained a good feel for things that can slow overall development, and things that can speed it.
I also have more than a few languages and projects under my belt. ;-)
But the fundamental issue here is pretty simple - the code just needs to be written. You're the guy that cares the most about it, so the ball's yours. Whether you want to start with the DialogManager, or clean up dialogs, or whatever is up to you. Personally, if I were you I'd start by getting the panels to dock into SPDesktop; that seems to be where the crux of the task is, the rest of this that we've discussed is just tangential to that.
Obviously, you'll need to do some hoisting to turn Inkscape::UI::Dialog::Dialog into Inkscape::UI::Dialog::Pane, and add some logic to allow it to operate in either panel or dialog mode. That is probably doable in a few evening's work.
The changes you'll need to do in DialogManager are pretty trivial, probably just requiring a few lines in verbs.cpp and an evening's work with search-and-replace.
Bryce
Quoting "Jon A. Cruz" <jon@...18...>:
In one case "showDialog()" can lead to a certain set of expectations, while "showUI()" or some such can help separate the mixed concepts.
Given how delayed the gtkmm work is at this point, I think this discussion is a case of the perfect being the enemy of the good.
The subtle shift in viewing things is much like the difference in coding with the assumption that a byte is a character. Far less work to code it with explicitly separated concepts to begin with than to go in later and try to split them in a refactoring.
Failing to completely separate the concepts may mean more work in the long-run, but continuing to debate this stuff rather than writing code may mean no work at all.
I do not expect the burden in this case to be comparable to that arising from bad byte/character assumptions. Let's just get this stuff done. We can fix the naming later.
I'm afraid that in order to convey things best I'll probably have to just code things up, but then again that's a good thing code-wise.
Exactly.
-mental
participants (5)
-
unknown＠example.com -
Bryce Harrington -
Jon A. Cruz -
Jon Phillips -
Ralf Stephan