Area Model
From KDevelop
Contents |
[edit] Imagine we have:
Area1:
- toolView for doc1
- view for doc2
- view for doc3
Area 2:
- toolView for doc1
- toolView for doc4
- view for doc2
- view for doc5
MainWindow1 (with no areas) MainWindow2 (with no areas)
[edit] Current Sublime Model of Operation (switching inside the same mainwindow)
- MainWindow1 is created
- Area1 is set for MainWindow1 (and its views are displayed)
- Area2 is set for MainWindow1 - all views from Area1 are closed and new ones for Area2 area opened
- despite area2 has a view for doc2 and toolview for doc1, they are still closed and recreated again
[edit] Current Sublime Model of Operation (switching between two mainwindows)
- MainWindow1 is created
- Area1 is set for MainWindow1 (and its views are displayed)
- MainWindow2 is created
- Area2 is set for MainWindow2 (and its views are displayed)
- MainWindow2 is switched to Area1
- Area1 gets cloned (because it's already displayed in MainWindow1) and becomes Area1(copy0)
- Area1(copy0) is displayed with all its views in MainWindow2
[edit] Current Sublime Model of Operation Limitations
- if Area2 was ever shown in MainWindow1 prior to creating a MainWindow2 with Area2 the Area2 will be cloned but there's no good reason to do this
- reconstruction can reuse the same widgets for area if it was ever shown (this is simply not implemented)
[edit] Big Questions So Far
- Shall we allow the same view be present in different areas at the same time?
- Pros (for allow):
- switching between two perspectives will not force to close toolviews (views) (see doc1 and doc2 examples above)
- it sounds logical to have the same set of editor windows in debug and code areas (like eclipse allows to have)
- Cons
- it's impossible to have the same view in areas shown in two different mainwindows
- same kind of functionality can be supported by documents showing one model in all its views
- xcode's mode of debugging doesn't allow to see the same editors in debugger window so it's debatable whether the same editor should be in both code and debug areas
- Pros (for allow):
[edit] IRC Conversation on the topic
[20:02] <teatime> adymo|mac: ok.. so what does it do?
[20:02] * teatime starts it again
[20:03] <adymo|mac> teatime: it starts two area-enabled mainwindows, each one is capable of switching between two predefined areas
[20:03] <apaku> teatime: Whooot. KMainWindow works perfectly.
[20:03] * apaku guesses the preview widget is the problem for KDialog and KAssistantDialog. Trying without that.
[20:03] <adymo|mac> teatime: now to switch area i sweep out the mainwindow and reconstruct it again
[20:04] <adymo|mac> teatime: to show the same area twice (i.e. in the second window) i make a copy of the area
[20:04] <teatime> apaku: awesome :)
[20:04] <apaku> teatime: Of course you loose the preview in the new form wizard.
[20:06] <teatime> adymo|mac: its hard to see what's a delect/create and what's a copy.. the views get cleared in any case
[20:07] <teatime> "delect"? I think I meant delete :)
[20:07] <teatime> adymo|mac: but anyway.. I think I understand what you mean
[20:07] <CIA-6> mlaurent * r619081 kexi/trunk/koffice/kexi/ (4 files in 4 dirs): Port++
[20:08] <teatime> adymo|mac: btw, I crash if I do any switching.. but I guess that's beside the point
[20:09] <adymo|mac> teatime: you'll have a (copy) at the titlebar for mainwindows with area clones
[20:09] <adymo|mac> teatime: wait. wait.. when do you crash?
[20:10] <teatime> adymo|mac: if I open the same perspective twice
[20:10] <teatime> adymo|mac: either by opening one mainwindow and switching from and back to a perspective
[20:10] <teatime> or opening both mainwindows, and then switching one of them
[20:11] <adymo|mac> teatime: this is strange because i don't crash:(
[20:11] <adymo|mac> teatime: have a backtrace?
[20:11] <teatime> adymo|mac: I probably built it differently..
[20:11] <teatime> no, crash dialog hasn't done anything useful for me in years..
[20:12] <teatime> I'll run it through gdb.. moment
[20:12] <apaku> teatime: :( Previews for KDialog and suclasses always work, but unfortunately they still freeze designer. Lets say what qt-interest knows...
[20:15] <teatime> adymo|mac: I get this: http://rafb.net/p/VVuq5n92.html
[20:16] <apaku> teatime,adymo|mac: /me doesn't crash on sublime when switching around area's.
[20:17] <teatime> btw, I updated qt-copy, kdelibs, kdepimslibs & kdevelop today
[20:18] <teatime> if at all relevant..
[20:19] * apaku didn't do that as its still breaking day ;)
[20:19] <adymo|mac> teatime: it tries to add 0 to a splitter,but i don't know why
[20:20] <adymo|mac> teatime: http://kdevelop.org/mediawiki/index.php/Area_Model
[20:23] <teatime> adymo|mac: paragraph 2 - don't you mean "Area2 is set for MainWindow1"? since it's meant to be a switch?
[20:23] <adymo|mac> teatime: could you please comment the line #141 in mainwindow.cpp and try to reproduce the bug again?
[20:23] * teatime tests
[20:24] <adymo|mac> teatime: yeah, for MainWindow1
[20:24] <apaku> teatime: don't want to disturb you two, but: Am I right that the AM doesn't support 2 different targets called the same for run-arguments?
[20:24] <teatime> apaku: not at all unlikely.. but I haven't checked
[20:25] <apaku> teatime: Well, it puts the arguments into /kdevautoproject/run/runarguments/targetname, so I suspect there are going to be problems if you have two targets with the same name...
[20:25] <teatime> adymo|mac: umm..since I'm in mcedit here.. line 141 is the clear() or area = 0?
[20:26] <adymo|mac> teatime: it's indexSplitters.clear()
[20:26] <teatime> apaku: what, you expected it to not be broken? ;)
[20:27] <teatime> adymo|mac: still crashes
[20:27] <teatime> apaku: but yeah.. that sounds likely to fail
[20:27] <apaku> teatime: Broken, of course. what else could it be. However I'm not in the mood to fix that. So lets make the QM as broken as the aM.
[20:27] * apaku hopes that only very few people use same subproject name in different parts of the project....
[20:28] <adymo|mac> teatime: heh, get a mac(tm) ;)
[20:28] <teatime> heh
[20:28] <adymo|mac> teatime: i can't crash it here
[20:29] <adymo|mac> apaku: only very few? see kdevelop source code ;)
[20:29] <adymo|mac> apaku: lib/ is everywhere :)
[20:29] <apaku> adymo|mac: Well, lib doesn't count because you can't execute it :)
[20:31] <teatime> apaku: couldn't we fix it simply by using the full "path" for the target name?
[20:31] <teatime> assuming we update the AM too, of course
[20:31] <apaku> teatime: Not unless we can guarantee that all parts of the path will be proper xml element names. You remember, we're storing the project in an XML file ;)
[20:32] <teatime> oh, fark
[20:32] <apaku> teatime: And I'm not sure if DomUtil::writeEntry("/some/long/path","") will create all the elements along the way.
[20:33] <apaku> teatime: We could do something like <runarguments><runargument value="arguments">/relative/path/to/project/target</runargument>
[20:34] <apaku> or <runargument><value>..</value><path>....</path></runargument> as I guess DomUtil isn't good at writing attributes.
[20:34] <apaku> teatime: But what about all the existing projects, how do we convert them?
[20:34] <teatime> we don't
[20:34] <apaku> teatime: BTW, we need to fix this for kdev4 ;)
[20:35] <teatime> no kidding.. ;)
[20:36] <teatime> apaku: fear of wiping someones old run arguments shouldn't keep us from fixing a broken system
[20:36] <teatime> that's a small cost
[20:36] <apaku> teatime: ever had a project with 100 binaries and different run arguments for each?
[20:37] <adymo|mac> teatime: ok, try to add "parent=0" line to AreaIndexPrivate(const AreaIndexPrivate &p) copy constructor in areaindex.cpp
[20:37] <teatime> apaku: no, and neither did anyone else using kdevelop ;)
[20:37] <apaku> teatime: Can DomUtil delete entries? In that case we could just leave the current reading code if the "new reading code" doesn't find anything and delete the old entry.
[20:38] <apaku> teatime: and saving will always store in new format.
[20:38] <teatime> I guess that's a reasonable approach
[20:38] <teatime> adymo|mac: ok.. should I back the other change?
[20:40] <adymo|mac> teatime: yes
[20:40] <teatime> adymo|mac: tried without doing that first.. and it works. no crash :)
[20:41] *** Helios- is now known as Helios.
[20:42] <adymo|mac> teatime: well. that clear() method is certainly not a problem ;)
[20:42] <adymo|mac> teatime: that's me who forgot to add a line to a copy constructor :)
[20:42] <teatime> yup. works fine now. back and forth, no problem
[20:43] <adymo|mac> teatime: ok, now you have exactly what i have
[20:43] <adymo|mac> teatime: so what do you think about the model i've described?
[20:43] * teatime continues reading the wiki
[20:43] <adymo|mac> teatime: refresh it first; )
[20:43] <teatime> did :)
[20:47] <adymo|mac> teatime: refresh again now :)
[20:47] <teatime> doh. I prefer the other one
[20:47] <teatime> now the hard part got longer ;)
[20:48] <teatime> hmm.. now the editors appeared.. I keep thinking of the toolviews
[20:49] <teatime> adymo|mac: I never used xcode, but it doesn't seem intuitive to not keep seeing the code if I start the debugger
[20:54] <adymo|mac> teatime: keep in mind that editors == toolviews in sublime ;)
[20:54] <teatime> adymo|mac: maybe I simply don't get it, but one feature of this design is that we treat toolviews and document views the same, right?
[20:54] <teatime> oh, right. lol :)
[20:55] <adymo|mac> teatime: i'll try to demonstrate you xcode... minute...
[20:56] <teatime> adymo|mac: but then.. if we do expect to support displaying of parts that only support 1doc-1view in multiple mainwindows.. do we have any choice but to do that for all our tools as well?
[20:58] <teatime> meaning we have to allow having the same... err.. I can't even express it. I think the model breaks down here
[20:59] <teatime> adymo|mac: I'm tempted to ask why we want to support multiple mainwindows
[21:00] [DCC] Asking teatime to accept upload of "Picture_3.png" (409.6 KB)...
[21:00] <adymo|mac> teatime: see the screenshot of xcode session,
[21:00] <teatime> I'm trying..
[21:00] <adymo|mac> it has as many "mainwindows" as possible ;)
[21:00] <teatime> timed out
[21:00] <adymo|mac> damn
[21:01] * adymo|mac takes his usb stick and proceedes with usual file-copy-share routine
[21:01] <teatime> adymo|mac: email? :)
[21:02] <adymo> teatime: http://adymo.pluron.com/Picture5.png
[21:03] [DCC] Upload of "Picture_3.png" to teatime failed. Reason: Timed out.
[21:03] <adymo|mac> teatime: i already got used to this procedure :)
[21:03] <adymo|mac> hmm. why dcc doesn't work... maybe i need to open some ports on the firewall....
[21:05] <teatime> not really sure what I learn from this.. hard to imagine working with editors in multiple mainwindows..
[21:05] <teatime> adymo|mac: is it a pure SDI interface?
[21:05] <adymo|mac> teatime: on your questions: 1) we will expect our plugins and documents to be able to create as much views as we need 2) total separation between debugger and code doesn't look that strange, at least once i've tried xcode i can assure you it's pretty natural
[21:06] <adymo|mac> teatime: when you start the debugger, your current code windows don't get touched, you'll simply see the breakpoint position in debugger window which is great imho
[21:07] <adymo|mac> teatime: btw, macos applications often have sdi+mdi mix ui :)
[21:07] <teatime> so it pops up a new mainwindow when you start the debugger?
[21:07] <adymo|mac> teatime: xcode and safari being the examples
[21:08] <adymo|mac> teatime: basically, to debug you open this window and then click debug
[21:08] <teatime> k..
[21:08] <teatime> hmm
[21:08] * teatime is curious to run it
[21:08] <adymo|mac> teatime: get a mac ;)
[21:08] <teatime> though perhaps not "buy a new mac" level of curious ;)
[21:08] <teatime> heeh
[21:08] <adymo|mac> lol
[21:09] <adymo|mac> teatime: seriously, at bof we thought about exactly this way of operations - with many mainwindows
[21:09] <adymo|mac> teatime: later mattr suggested that he would want to do all this in a single mainwindow so i sorta implemented it
[21:10] <teatime> "and thus, our troubles began.." ;)
[21:10] <adymo|mac> teatime: but my implementation is of course having its problems because it is not designed/optimized for this case :)
[21:11] <adymo|mac> teatime: yes, but still, the troubles are pretty minimal - how many views do we want to share between "code", 'debug" and "design" areas?
[21:12] <adymo|mac> with xcode-like operations usual views will be different, so only toolviews remain
[21:12] <teatime> adymo|mac: that hardly matters, does it? as soon as it is >1 it's "n" ;)
[21:12] <adymo|mac> teatime: but which toolviews? fileselector?
[21:12] <adymo|mac> it can show the same kdirmodel in different views
[21:13] <teatime> adymo|mac: hmm.. are you saying we should restrict some tools, to only ever be in one perspective?
[21:13] <adymo|mac> teatime: no, potentially they will be available in every area, but not shown by default
[21:13] <adymo|mac> (like in eclipse when you can add each of 1000 toolviews to all areas )
[21:14] <teatime> I think I'm simply not used to think in MVC.. I keep thinking of how hard our current tools would be to port to this design
[21:14] <adymo|mac> teatime: hard. but imho necessary
[21:17] <teatime> adymo|mac: so what's the remaining issue, assuming we make this requirement for all our views?
[21:17] <teatime> wouldn't it be possible to move an open view between perspective shifts inside the same mainwindow
[21:17] <teatime> but cloning it when making a new mainwindow?
[21:17] <adymo|mac> teatime: wait, what do you mean?
[21:18] <teatime> adymo|mac: I think I'm trying to answer the Big question with "yes" :)
[21:19] <adymo|mac> teatime: ah:)
[21:19] <adymo|mac> teatime: ok, you don't want to move, you want to "keep"
[21:19] <teatime> since, as I understand it, if a view is in several areas that belong to the same mainwindow, it's only one view and it's only visible in one place
[21:19] <teatime> so "keep", yeah I guess :)
[21:20] <adymo|mac> teatime: that's if you answer "yes" to a "big question" :)
[21:21] <teatime> adymo|mac: the opposite feels harder to imagine
[21:21] <adymo|mac> teatime: currently you'll have the view to the same document, but it will be different view (think of another cursor position, selection, etc.)
[21:21] <teatime> right..
[21:22] <teatime> hmm.. actually, for the editing vs debug perspectives (within the same mainwindow) I guess I can see the point of a new view
[21:22] <teatime> but not really for toolviews.. I'd just be surprised, I think, if the fileselector changed directory when I changed perspective
[21:23] <adymo|mac> teatime: me too, but that's exactly what fileselector can overcome with mvc
[21:24] <teatime> sure, but if it's showing me the same thing anyway.. why create a new view?
[21:24] <adymo|mac> or with a bit of initialization
[21:24] --> ziza has joined this channel (n=aziz@chello084112072063.6.11.vie.surfer.at).
[21:25] <adymo|mac> teatime: well, that's the hard question...
[21:25] <adymo|mac> teatime: technically it's possible in sublime to add a view into two or more areas
[21:26] <teatime> is it? maybe in implementation terms, but.. if I have one view, kept between perspective shifts, then it will look the same no matter how often I shift
[21:26] <teatime> that was "is it?" to your previes line..
[21:26] <adymo|mac> teatime: but when you decide to show this area in another mainwindow, you'll end up having only one widget for two mainwindows
[21:27] <teatime> adymo|mac: yes, I guess my point is we can't pretend a perspective shift and a new mainwindow is the same thing.. they need to be treated differently
[21:27] <adymo|mac> teatime: then i should improve the design...
[21:27] <teatime> we _need_ a new view for a new mainwindow.. between perspective shifts within the same mainwindow.. I just see overhead
[21:28] <teatime> adymo|mac: :(
[21:28] <adymo|mac> teatime: kiss principle always works this way :)
[21:28] <teatime> heh. true. implement when needed :)
[21:28] <adymo|mac> currently i have the simplest possible design
[21:29] <adymo|mac> (it's already 2ksloc of code though :()
[21:30] <teatime> adymo|mac: how does all this fit with the toplevel ui mode kdev4 currently sports?
[21:30] <adymo|mac> eh?
[21:30] <teatime> or rather, supports
[21:30] <teatime> supported?
[21:30] * teatime checks
[21:31] <teatime> adymo|mac: settings->general->UI
[21:31] <teatime> docked or multi toplevel
[21:32] <adymo|mac> teatime: actually i plan no toplevel mode
[21:32] <teatime> maybe that's just a free feature of the qt4 docks
[21:33] <teatime> adymo|mac: I guess I should buy those two screens I want.. so I'll want toplevel mode ;)
[21:34] <adymo|mac> teatime: if that's for free with qt4 docks then we of course have it in sublime too
[21:34] <teatime> but if we do multiple mainwindows as well as xcode seems to, I guess the need for toplevel is reduced significantly
[21:34] <adymo|mac> teatime: but the point is that you can always clone your current area and put it onto another screen
[21:34] <apaku> Hmm, CC fails for me :(
[21:35] <teatime> apaku: everywhere? where in the code are you?
[21:35] <apaku> Having TrollProjectWidget* prjWidget member variable and trying prjWidgte-><ctrl+space> gives me "parameter check failed"
[21:35] <apaku> teatime: ProjectConfigurationDlg in QM
[21:36] <adymo|mac> teatime: i've looked at the code and i think that i can be a bit smarter at creating widgets and actually provide support for "keeping" views
[21:36] <teatime> apaku: same here
[21:37] <apaku> teatime: :( But why?
[21:37] <teatime> adymo|mac: sounds good :)
[21:37] <apaku> teatime: Same for myProjectItem.
[21:37] <adymo|mac> teatime: what i need is a view widget pool so that view can decide whether to create a new widget or reuse existing one
[21:37] <teatime> apaku: dunno.. this is a new error message for me
[21:37] <adymo|mac> teatime: at least this sounds doable for toolviews
[21:38] <adymo|mac> teatime: for usual views it wil be probably harder
[21:38] <teatime> adymo|mac: for the 1doc-1view kparts it's almost essential
[21:38] <adymo|mac> heh.. so much to do
[21:39] <apaku> teatime: Maybe because its a .ui subclass....
[21:39] <apaku> teatime: Bugreport or mail to kdevelop-devel? Which one is zwabel going to read?
[21:39] <adymo|mac> teatime: no, not for the reasons i've explained tonight... we can have 1 document -> N kparts correspondence
[21:40] <teatime> apaku: I'd say the ml is more likely
[21:40] <adymo|mac> teatime: i don't embed a kpart into sublime area
[21:40] <adymo|mac> i use a view that can have 1 to 1 correspondence with kpart and which can have its widget
[21:41] <adymo|mac> but.... if i make views to share their widgets as much as possible then the whole ui will be a lot faster of course
[21:42] <adymo|mac> because it would avoid kpart creation...
[21:42] <adymo|mac> ok, convinced... have to implement this
[21:42] <teatime> adymo|mac: exactly :)
[21:42] <teatime> adymo|mac: I kept erasing there.. everything I wrote, you wrote before me :)
![[Main Page]](/graphics/theme3/KDevelopBigIcon.png)