freenode/#sicl - IRC Chatlog
Search
5:37:24
beach
And it now looks to me like we could design a bunch of panes each with its own display function. Then those panes could be assembled in different ways according to the taste of the programmer.
5:42:33
beach
Now, I am asking myself, is there any purpose in showing compilation messages the way they are done when I compile in a terminal. I would think that in an IDE, the programmer would rather want them in some code pane as tool tips on annotated code.
5:43:57
beach
I can see myself clicking on a button that then starts (asdf:load-system...) and no messages like "compiling this or that". Just (say) a bunch of tabs (or something better), one for each file containing a compilation message.
6:16:09
jackdaniel
so opening a pane for each file when you only want to load your system with these botched dependencies would be suboptimal
6:17:27
jackdaniel
if the file is opened and it is feasible, then annotations could be added and that pane/tab should gain some highlight that something has changed; but that shouldn't substitute "traditional" compilation stream log
6:19:06
beach
I guess we would have to make such a pane as well, and let the user choose whether to include it.
6:21:10
beach
But I think pjb is right in that I need to determine some workflow first, and then see how that workflow would be best supported with a bunch of panes.
6:24:36
jackdaniel
where each tool is a separate frame, and then adopt these frames in a single frame and add some piping (not ready in McCLIM yet)
6:24:58
jackdaniel
adoption of frames is not ready yet* but I have a working proof of concept with a shared pointer documentation, menu etc
6:46:59
beach
I think the solution with multiple frames is great when you have to add a program that was written as an independent application, but when you can design the entire thing from scratch, my hunch is that a single application frame is better.
7:01:34
jackdaniel
having integrated environment provides, well, better integration :) so I believe that your hunch is correct
7:01:57
jackdaniel
by piping I mean: "adding necessary plumbing so independent components communicate with each other"
7:02:28
jackdaniel
re designing from independent comopnents: a benefit of having such design is that you may rip one component for your purpose and easily reuse it
7:14:29
beach
So this discussion seems to suggest a design like Drei/Climacs, i.e., a pane class that does most of the stuff that needs to be done in a pane, and then an application frame that uses that pane as its main component, possibly adding functionality that a complete application needs.
7:18:47
jackdaniel
beach: what I'm thinking is more a monolithic climacs (a frame), that is adopted as a frame-pane in the ide as an editor
7:20:44
beach
I understand your idea. And I am saying that, if integration of a single pane is easier, then having an editor written as a pane class plus an application could make it possible to choose. A separate application can then use the pane class or the entire application.
7:21:24
beach
The idea of Drei was that it wasn't necessarily useful, say in the listener, to have a mode line, commands for finding files, splitting panes, etc.
7:21:52
beach
So that part became part of the complete Climacs application, and the pane class could be used independently.
7:23:04
jackdaniel
I think that drei is specific in many regards (i.e in that it implements i.e the input editing pane and relies on some mcclim-specific behaviors), so it is not a good example for such design (or maybe it is since it was reused in many places)
7:23:59
beach
Sure, it is entirely possible that I overgeneralize the usefulness of this kind of design.
7:24:07
jackdaniel
but yes, if you want to have ide, then pane classes and single frame provides the best integration
7:24:46
jackdaniel
on the other hand, it makes sense to have each component to have its own command table and translators (in other words - to be a frame that can be adopted as a pane)
7:25:24
jackdaniel
possibly such adopted frames would have multiple layouts where one is specifically tailored for embedding (i.e a single pane withotu toolboxes and the interactor)
7:25:53
jackdaniel
a frame that acts as a frame manager could have a non-standard command table which dynamically inherits from all adopted frames
7:26:11
jackdaniel
so you would have one interactor for all command tables (and one set of translators etc) for integration
7:27:28
jackdaniel
you could think of panes as widgets in other toolkits, while the frame stands fro an application