On Tue, 20 Jul 2010 06:57:01 -0400, Lars T. Kyllingstad <public@kyllingen.nospamnet> wrote:

> On Sun, 18 Jul 2010 22:44:27 +0000, dsimcha wrote:
>> == Quote from BLS (windevguy@hotmail.de)'s article
>
>>> Next, Do you have any ideas about zooming ? (zooming a plotting region)
>>> ?
>>
>> This can already be done programmatically (see Figure.xlim() and
>> Figure.ylim()), but is not exposed yet via the default plot window GUI.
>> This will be exposed when I decide how I want to expose it.  The most
>> obvious answer is dragging, but the question then becomes, how do you
>> zoom back out?
>
> How about the mouse wheel?  That's always the first thing I try.
>
> -Lars

I generally consider mouse-wheel == scroll and crtl + mouse-wheel == zoom

dsimcha wrote:

> == Quote from BLS (windevguy@hotmail.de)'s article
>> On 19/07/2010 00:01, BLS wrote:
>> > On 18/07/2010 22:36, dsimcha wrote:
>> >> heat maps
>> >
>> > Sorry for my ignorance,
>> > What are heat maps good for ?
>> >
>> > Since I am more biz software guy, here my question.
>> >
>> > Let's say I have this relation
>> >  >A Project can have several Cost Centers.
>> >  >A Cost Center can have several cost items.
>> >
>> > I our sample . Project -P- has say, 10 cost centers.
>> > Cost Center no 1 takes already 60 percent.
>> > The other cost centers (2-10) just take between 10 (blue) and 20
>> > (green) percent.
>> >
>> > -- So I want to color cost center no 1 related items in red.. . and the
>> > max percentage item in cost center no 2 dark red.
>> > CC No 1 = {5,20,20,15}
>> >
>> > Is this what a heat map is made for ?
>> >
>> > and sorry , best example I am able to give atm..
>> > bjoern
>> My guess was okay, Heat maps are also made for this use case. so no need
>> to answer.
>> Since Tree maps are not that different from Heat maps, do you have any
>> plans to implement them too ?
> 
> I didn't have any plans to implement them, as I didn't know about them
> until I
> looked them up on Wikipedia just now.  I'll consider implementing them,
> but I'm not sure if it will happen soon.
> 
>> Next, Do you have any ideas about zooming ? (zooming a plotting region) ?
> 
> This can already be done programmatically (see Figure.xlim() and
> Figure.ylim()),
> but is not exposed yet via the default plot window GUI.  This will be
> exposed when
> I decide how I want to expose it.  The most obvious answer is dragging,
> but the question then becomes, how do you zoom back out?

I don't think that you should hard code something like user interaction,
just provide the methods for interaction such as:
zoom on reqion(x,y,w,h), user input could be dragging a rectangle
zoom to(here%), user input could be scrolling, ctrl scrolling or a input box
move view(x,y), user input could be scrolling, or holding MMB

-Rory

dsimcha wrote:

> == Quote from Rory Mcguire (rjmcguire@gm_no_ail.com)'s article
>> Do you plan on supporting QT/KDE?
>> -Rory
> 
> Long term, probably.  Short term, probably not.  QtD is, from what I
> understand,
> not very mature yet.  I had a @#)#* of a time working through bugs,
> inadequate documentation, missing features and general lack of polish in
> gtkD and DFL, and those are (according to this page:
>http://www.wikiservice.at/d/wiki.cgi?action=browse&id=GuiLibraries&oldid=AvailableGuiLibraries)
> considered more mature than QtD.
> 
> This is not a knock on the developers of these libraries, as I understand
> that it takes time to create a mature GUI library/binding and the
> situation is
> continuously improving.  It's just that it's hard to build on that
> unstable/immature a foundation.  Once QtD matures to at least the point of
> DFL and gtkD, I'll seriously consider a port, but until then don't get
> your hopes up.
> 
> On the other hand, once I'm done refactoring things, I hope that the
> dflwrapper and gtkwrapper files will serve as useful examples, so that
> others can contribute
> the code to do a port.  This should not be very hard for someone who
> already knows
> a given GUI framework well to write.  Basically, you just need to create a
> default plot window and subplot widget, and wrap a few drawing primitives
> in a compile-time interface.

If you use the pixmap backend of cairo then all one would have to do to support QT/KDE is add an interface to control the second tier of your lib.

-Rory

== Quote from Rory Mcguire (rjmcguire@gm_no_ail.com)'s article
> dsimcha wrote:
> > == Quote from Rory Mcguire (rjmcguire@gm_no_ail.com)'s article
> >> Do you plan on supporting QT/KDE?
> >> -Rory
> >
> > Long term, probably.  Short term, probably not.  QtD is, from what I
> > understand,
> > not very mature yet.  I had a @#)#* of a time working through bugs,
> > inadequate documentation, missing features and general lack of polish in
> > gtkD and DFL, and those are (according to this page:
>
>http://www.wikiservice.at/d/wiki.cgi?action=browse&id=GuiLibraries&oldid=AvailableGuiLibraries)
> > considered more mature than QtD.
> >
> > This is not a knock on the developers of these libraries, as I understand
> > that it takes time to create a mature GUI library/binding and the
> > situation is
> > continuously improving.  It's just that it's hard to build on that
> > unstable/immature a foundation.  Once QtD matures to at least the point of
> > DFL and gtkD, I'll seriously consider a port, but until then don't get
> > your hopes up.
> >
> > On the other hand, once I'm done refactoring things, I hope that the
> > dflwrapper and gtkwrapper files will serve as useful examples, so that
> > others can contribute
> > the code to do a port.  This should not be very hard for someone who
> > already knows
> > a given GUI framework well to write.  Basically, you just need to create a
> > default plot window and subplot widget, and wrap a few drawing primitives
> > in a compile-time interface.
> If you use the pixmap backend of cairo then all one would have to do to
> support QT/KDE is add an interface to control the second tier of your
> lib.
> -Rory

In theory yes, but do we really want to have this many dependencies?  One thing I'm going to insist on in the management of this project is that there be no dependencies except for the GUI toolkit being used, so people don't find it impossible to install.

== Quote from Rory Mcguire (rjmcguire@gm_no_ail.com)'s article
> dsimcha wrote:
> > == Quote from BLS (windevguy@hotmail.de)'s article
> >> On 19/07/2010 00:01, BLS wrote:
> >> > On 18/07/2010 22:36, dsimcha wrote:
> >> >> heat maps
> >> >
> >> > Sorry for my ignorance,
> >> > What are heat maps good for ?
> >> >
> >> > Since I am more biz software guy, here my question.
> >> >
> >> > Let's say I have this relation
> >> >  >A Project can have several Cost Centers.
> >> >  >A Cost Center can have several cost items.
> >> >
> >> > I our sample . Project -P- has say, 10 cost centers.
> >> > Cost Center no 1 takes already 60 percent.
> >> > The other cost centers (2-10) just take between 10 (blue) and 20
> >> > (green) percent.
> >> >
> >> > -- So I want to color cost center no 1 related items in red.. . and the
> >> > max percentage item in cost center no 2 dark red.
> >> > CC No 1 = {5,20,20,15}
> >> >
> >> > Is this what a heat map is made for ?
> >> >
> >> > and sorry , best example I am able to give atm..
> >> > bjoern
> >> My guess was okay, Heat maps are also made for this use case. so no need
> >> to answer.
> >> Since Tree maps are not that different from Heat maps, do you have any
> >> plans to implement them too ?
> >
> > I didn't have any plans to implement them, as I didn't know about them
> > until I
> > looked them up on Wikipedia just now.  I'll consider implementing them,
> > but I'm not sure if it will happen soon.
> >
> >> Next, Do you have any ideas about zooming ? (zooming a plotting region) ?
> >
> > This can already be done programmatically (see Figure.xlim() and
> > Figure.ylim()),
> > but is not exposed yet via the default plot window GUI.  This will be
> > exposed when
> > I decide how I want to expose it.  The most obvious answer is dragging,
> > but the question then becomes, how do you zoom back out?
> I don't think that you should hard code something like user interaction,
> just provide the methods for interaction such as:
> zoom on reqion(x,y,w,h), user input could be dragging a rectangle
> zoom to(here%), user input could be scrolling, ctrl scrolling or a input box
> move view(x,y), user input could be scrolling, or holding MMB
> -Rory

The point isn't to hardcode this directly into the Figure object.  What you
suggest can already be done by calling xLim() and yLim() and then redrawing.
However, Plot2Kill has the concept of a default plot window, which is displayed by
showAsMain() and returned by getDefaultWindow().  The point of this is so that if
someone wants to put up a quick plot, they don't need to set up a window manually.
 At the default plot window level, I don't see either how to avoid hard-coding
this or why hard-coding it would be bad.

dsimcha wrote:

> == Quote from Rory Mcguire (rjmcguire@gm_no_ail.com)'s article
>> dsimcha wrote:
[snip]

> The point isn't to hardcode this directly into the Figure object.  What
> you suggest can already be done by calling xLim() and yLim() and then
> redrawing. However, Plot2Kill has the concept of a default plot window,
> which is displayed by
> showAsMain() and returned by getDefaultWindow().  The point of this is so
> that if someone wants to put up a quick plot, they don't need to set up a
> window manually.
>  At the default plot window level, I don't see either how to avoid
>  hard-coding
> this or why hard-coding it would be bad.

Ah right.

If you made the app able to select what to use at runtime that would be awesome :).


cat data | plot2kill -stdin -gtk
cat data | plot2kill -stdin myplot.png

:D

What can the app currently do?
What have you decided is app and what is lib?
Is the code that draws the lines etc.. pluggable?

:) maybe I should just checkout your code.

I was beginning to feel that D was slow, but then "emplace, scope, enforce [Was: Re: Manual...]" in digitalmars.D showed me otherwise, so now I'm all excited to try some of the stuff I actually use at work.






-Rory

dsimcha wrote:

> == Quote from Rory Mcguire (rjmcguire@gm_no_ail.com)'s article
>> dsimcha wrote:
>> > == Quote from Rory Mcguire (rjmcguire@gm_no_ail.com)'s article
>> >> Do you plan on supporting QT/KDE?
>> >> -Rory
>> >
>> > Long term, probably.  Short term, probably not.  QtD is, from what I
>> > understand,
>> > not very mature yet.  I had a @#)#* of a time working through bugs,
>> > inadequate documentation, missing features and general lack of polish
>> > in gtkD and DFL, and those are (according to this page:
>>
>>http://www.wikiservice.at/d/wiki.cgi?action=browse&id=GuiLibraries&oldid=AvailableGuiLibraries)
>> > considered more mature than QtD.
>> >
>> > This is not a knock on the developers of these libraries, as I
>> > understand that it takes time to create a mature GUI library/binding
>> > and the situation is
>> > continuously improving.  It's just that it's hard to build on that
>> > unstable/immature a foundation.  Once QtD matures to at least the point
>> > of DFL and gtkD, I'll seriously consider a port, but until then don't
>> > get your hopes up.
>> >
>> > On the other hand, once I'm done refactoring things, I hope that the
>> > dflwrapper and gtkwrapper files will serve as useful examples, so that
>> > others can contribute
>> > the code to do a port.  This should not be very hard for someone who
>> > already knows
>> > a given GUI framework well to write.  Basically, you just need to
>> > create a default plot window and subplot widget, and wrap a few drawing
>> > primitives in a compile-time interface.
>> If you use the pixmap backend of cairo then all one would have to do to
>> support QT/KDE is add an interface to control the second tier of your
>> lib.
>> -Rory
> 
> In theory yes, but do we really want to have this many dependencies?  One thing I'm going to insist on in the management of this project is that there be no dependencies except for the GUI toolkit being used, so people don't find it impossible to install.

Could the toolkits it uses not be specified on the command line so that it only uses the dependencies you choose it to?

e.g.:
dmd *.d -version=gtk
or
dmd *.d -version=cairo_cli

== Quote from Rory Mcguire (rjmcguire@gm_no_ail.com)'s article
> dsimcha wrote:
> > == Quote from Rory Mcguire (rjmcguire@gm_no_ail.com)'s article
> >> dsimcha wrote:
> >> > == Quote from Rory Mcguire (rjmcguire@gm_no_ail.com)'s article
> >> >> Do you plan on supporting QT/KDE?
> >> >> -Rory
> >> >
> >> > Long term, probably.  Short term, probably not.  QtD is, from what I
> >> > understand,
> >> > not very mature yet.  I had a @#)#* of a time working through bugs,
> >> > inadequate documentation, missing features and general lack of polish
> >> > in gtkD and DFL, and those are (according to this page:
> >>
>
>>http://www.wikiservice.at/d/wiki.cgi?action=browse&id=GuiLibraries&oldid=AvailableGuiLibraries)
> >> > considered more mature than QtD.
> >> >
> >> > This is not a knock on the developers of these libraries, as I
> >> > understand that it takes time to create a mature GUI library/binding
> >> > and the situation is
> >> > continuously improving.  It's just that it's hard to build on that
> >> > unstable/immature a foundation.  Once QtD matures to at least the point
> >> > of DFL and gtkD, I'll seriously consider a port, but until then don't
> >> > get your hopes up.
> >> >
> >> > On the other hand, once I'm done refactoring things, I hope that the
> >> > dflwrapper and gtkwrapper files will serve as useful examples, so that
> >> > others can contribute
> >> > the code to do a port.  This should not be very hard for someone who
> >> > already knows
> >> > a given GUI framework well to write.  Basically, you just need to
> >> > create a default plot window and subplot widget, and wrap a few drawing
> >> > primitives in a compile-time interface.
> >> If you use the pixmap backend of cairo then all one would have to do to
> >> support QT/KDE is add an interface to control the second tier of your
> >> lib.
> >> -Rory
> >
> > In theory yes, but do we really want to have this many dependencies?  One thing I'm going to insist on in the management of this project is that there be no dependencies except for the GUI toolkit being used, so people don't find it impossible to install.
> Could the toolkits it uses not be specified on the command line so that it
> only uses the dependencies you choose it to?
> e.g.:
> dmd *.d -version=gtk
> or
> dmd *.d -version=cairo_cli

That's exactly the way it works now, except that for Cairo I'm using the gtkD Cairo wrappers, rather than "raw" Cairo.  As far as selecting at runtime instead of compile time, this is almost a definite "won't happen" because IMHO it's massive overengineering for relatively little benefit, and would make the project substantially more complicated in both its internals and its public API.

== Quote from Rory Mcguire (rjmcguire@gm_no_ail.com)'s article
> What can the app currently do?
> What have you decided is app and what is lib?

The whole thing is a lib as opposed to an app.  It's just that it's designed to be a very high level lib, and has a default plot window.  In other words, if you don't feel like writing your own window to display the plot in, the lib contains one with sane defaults for the relevant policies.  You can do something like:

auto myWindow = Histogram(someNumbers, 100).toFigure.getDefaultWindow;
myMainWindow.add(myWindow);
myWindow.showAll();