[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    RE: Latest snapshot (980106)
From:       Sven Radej <a9509961 () unet ! univie ! ac ! at>
Date:       1998-01-06 16:19:35
[Download RAW message or body]


On 06-Jan-98 Russ Steffen wrote:
> Two big issues with the lastest snaphost:
> 
> 1) The new KToolBar has some problems. First, when placed vertically
>     the width that it choses is wider than the handle, and looks weird.
>     And, kpat segfaults when the toolbar is undocked. I guessing that
>     might be kpat's fault, since nothing else seems to have a problem.

No, It's result of one-button-solution. Will be fixed. Thanks for the
report.

(one hour later)

Er.. it seems to be deep problem... will take day or two to fix.
Who the h... got that idea to put _only__one_ button in toolbar?! I'm not
angry, I'm just astonished; There is no way to predict what one could use
toolbar for, so thank you for your ideas, bugreports, and keep them
sending. 

And when I'm complaining:

*Bars and KNotes have the same way of mooving on the screen: slowly and
painfully. I think that other things like toolboxes or something will
sooner or later need some way of walking on the screen.

I think that with perfect window manager like KWM we really don't need
ultra-complex mouseMoveEvent implementations;

what we need (Hallo, Matthias!) is:

- little window-titles with close (and maybe roll-up/down!) buttons
  (something like KWM::setDecoration(winId(), 3); )

and

- cooperative moving/resizing

  When I say cooperative, I mean (limeted) cooperation between *Bar,
  toolBox or something, and KWM. Window should be aware of it's (or
  rectangle's) position on end of moving/resizing so it can move/resize  
  itself according to it's needs (which are: occupy minimum of screen and
  try to dock itself back to parent if possible.

  example: (resizing, KWM in transparent mode)

        * on construction, toolBar tells KWM that it wants to be specially
          managed.
        * User resizes toolBar with mouse. KWM draws dragging rectangle.
        * When user finishes resizeing (i.e. mouse is released) KWM
          doesn't send resizeEvent but just informs toolBar about it's new
          geometry.
        * ToolBar  computes new button layout and resizes itself

  Why? Becouse there is no way for toolBar to know who resized it: KWM or
  toolBar itself. And in resizeEvent toolBar is allready drawn with new
  geometry (so when it changes it's geometry again it looks ugly and
  flickering)

---
Sven (deep in updateRectangles,resizeEvent and 
      minimumWidth=(hasToolBarOnlyOneButton &&
      !horizontal)?TOOLBARHEIGHT:TOOLBARHEIGHT+4+9

[prev in list] [next in list] [prev in thread] [next in thread]