You can subscribe to this list here.
2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
(20) |
Sep
(87) |
Oct
(22) |
Nov
(2) |
Dec
(7) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2007 |
Jan
(9) |
Feb
(10) |
Mar
(73) |
Apr
(62) |
May
(79) |
Jun
(75) |
Jul
(28) |
Aug
(4) |
Sep
(2) |
Oct
(27) |
Nov
(18) |
Dec
(2) |
2008 |
Jan
(6) |
Feb
(15) |
Mar
(19) |
Apr
(10) |
May
(82) |
Jun
(152) |
Jul
(17) |
Aug
(19) |
Sep
(20) |
Oct
(21) |
Nov
(7) |
Dec
(3) |
2009 |
Jan
(11) |
Feb
(7) |
Mar
(18) |
Apr
(15) |
May
(13) |
Jun
(20) |
Jul
(20) |
Aug
(21) |
Sep
|
Oct
(16) |
Nov
(34) |
Dec
(40) |
2010 |
Jan
(36) |
Feb
(17) |
Mar
(66) |
Apr
(8) |
May
(13) |
Jun
(10) |
Jul
(2) |
Aug
(27) |
Sep
(26) |
Oct
(26) |
Nov
(3) |
Dec
(3) |
2011 |
Jan
(3) |
Feb
(6) |
Mar
|
Apr
(9) |
May
|
Jun
(3) |
Jul
(3) |
Aug
(8) |
Sep
|
Oct
|
Nov
(1) |
Dec
|
2013 |
Jan
|
Feb
|
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
|
Sep
|
Oct
(3) |
Nov
(2) |
Dec
|
2014 |
Jan
|
Feb
|
Mar
(6) |
Apr
|
May
|
Jun
(21) |
Jul
|
Aug
(4) |
Sep
|
Oct
(2) |
Nov
|
Dec
|
2015 |
Jan
|
Feb
(2) |
Mar
|
Apr
|
May
(18) |
Jun
|
Jul
|
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
|
2016 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(2) |
Dec
(3) |
2017 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
(1) |
Oct
|
Nov
|
Dec
|
2019 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2020 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Alex G. <gs...@cs...> - 2006-09-10 07:14:34
|
> If I understand you well, it's drawing the whole basket into a big picture, > so that we when we hide the basket and show it again, it's snappy. No, it is for animation to be smooth. > > But is it really needed? > - Every single note is already double-bufferised. Mainly for animation > purpose. > - Colored background is paint in one shot by filling rectangles wil plain > color. > - And semi-transparent background images are already cached so that no > transparency computation is to be done only once, and afterward, it's all > about painting pixmaps on screeen byte per byte. Really fast. My problem was not speed. It was the complexity of the code - if you can do something in a simple way and get the same speed as doing it in the complex way, I think the simple one is preferrable. > > If I do not misunderstood, this global buffer is slowering the drawing > because: > - For each frame of the animation, notes... have to be drawn to the global > buffer and then the buffer is drawn on screen > - But that also means on each frame, the notes draws are not from the note > buffer, but each note should be re-drawn one more time. Really slow. That has to be measured. In any case, it's possible to leave the note buffers intact. > - Modern X11 systems (Xgl, aXgl, Compiz and co.) already have a persitent > back-store per window, so it's one more layer of bufferization, making > yours useless. Well, if I had to find the optimal solution, I think that ultimately, we should have BasketView that uses the Qt4's GraphicsView (the advanced Canvas), which is itself highly optimized for things like this. But then, all the smart painting code, including the one for empty rectangles will be anyway obsolete. > > If I'm right, and you removed every double-buffers to replace them all by a > big buffer per basket, then I will explain to you all the little tricks > that are made to make the drawing as fast as possible. > They are numerous and not that easy to understand, but it's the solution I > came up that give the best results, best caching, and reduce as many redraw > as possible. > I've done the code while my graphics acceleration was not working, without > any graphics card driver. The first Make-it-Cool versions were not that > fast, but weeks after weeks, as I added ever fine-tuning tricks, it became > fast, even with baskets with background images. Before the optimisations, I > tought to removed the background images feature. But not anymore. Well, it's a tough question. My computer is fast, and the acceleration is working OK :), so it's hard to me to test the performance on a slow machine. However, as I understand it, your code paints the whole area anyway - you just avoid painting the non-empty rectangles with the background (which is, in the best case, a 2x speedup), and the copying of the pixmap to the screen (which is quite fast by itself). OK, one problem I see with that is that it's going to be slow on a networked X connection... Still, I believe that if we use QGraphicsView, we won't have to worry of that (BTW., did you consider using QCanvas?) > > > I also want to try to remove the corresponding smartness from the Notes - > > just let them paint whatever they want and let the double buffering > > handle the smoothness. Looks like it's going to work just as well. > > So, you will remove the buffering of every notes, and replace them by one > big Animations will suffer from it, especially for baskets with big > background pixmaps. OK, I don't know - I didn't do this straight away 'cause I wanted to measure the performance before doing it. But now, again, I think I'll delay it until Qt 4 anyway. > Please explain what you were wanting to achieve. > Then we will see if it's the right way to go. To make the code as simple as possible, provided that the performance is not much impacted :) > > Ah, so you removed the empty-area computation?! > So you draw everything off-screen, even if that means drawing some pixels > several times?! > Hum... bad. The point was, I couldn't discern any difference in the speed (ok, admitted, my comp is fast). > > I know the empty-areas are hard to understand, but it's efficient. > Oh, and let me know if I'm wrong and totally misunderstood your changes ;-) No, you didn't. > > > I've also refactored the code of the animation into a separate class > > called Animator. Haven't integrated it yet, but I wrote a small test for > > it, called basket_animator_test. You can play with it, checking different > > parameters of the animation - I've finally found the parameters that look > > best to me, but you can experiment... > > Again: why, and for what benefit? > And how? The benefit is, again, code simplification. The current class Basket does everything including everything, and it's very hard to do changes without breaking something. The solution to that is to break it into several orthogonal components, and splitting out things that can be neatly made into a class is the way to do it. However, I now see that, again, the Qt4's QGraphicsView has a nice support for animations, so I think I'll postpone all of these changes, and see if we can use QGraphicsView for basket. > Nice. > But I think I will apply my sentence "when it works, don't touch" and keep > autotools for KDE 3. > Is cmake integrated into KDevelop? Not sure right now, but it definitely will be, given that cmake is the official build tool for KDE 4. > Does KDevelop still knows the list of files in the projects so that > Ctrl+Shift+O works again? er, no idea... I never used that. > Do you have detected libGPGme and libgpg-error? > Do you have detected libkdepim? I bet these are either done already or will be in the near future... again, Basket is not the only KDE program that uses gpg... > Does it displays a nice message to users, at configure time, to tell them > what packages to install (see file configure.in.bot). I believe you can do that very easily from CMakelists.txt. > > All in all, it's a nice news we have someone who knows Cmake when we will > migrate to KDE4. Oh... can't wait for that already ... > Then it WILL be included. > > > Just click somewhere inside the window to see the animation. Now, it > > repaints all the screen every time, so the speed should be about the same > > if you move one rectangle or 100, as long as their total area is about > > the same as that of the viewport. > > Seems I do not have CMake. > Yast2 do not find packages for it. > I will not loss time trying to install it on SuSe since I will migrate to > my new Kubuntu-based computer soon. Well, I have a 6.06.1 Kubuntu, and it's cmake is too old anyway (it's 2.2, when you need 2.4.2 at least. > > Will test it when I have fully migrated to Kubuntu, understood that system > and fixed the bugs apt-get give me (hum yeah... I took the BETA version of > KUbuntu, so I have wired behaviours). Should be OK. I'm on kubuntu for 1/2 year already, so far it's fine. > Regards, Alex |
From: <sl...@li...> - 2006-09-09 16:13:03
|
As promised some days ago, here is an explanation of how copy/paste current= ly=20 works in 0.6.0: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D =46irst, there is the class ExtendedTextDrag at the bottom of notedrag.cpp. It's a QTextDrag, enhanced to support some special cases: =2D When copying an HTML from Firefox, it always use UTF-16 for encoding the MIME type "text/html", insted of the system encoding. I detect it with the first two bytes: "=FF=FE", and tell Qt to read it as= UTF16. =2D Some older versions of GNOME, GEdit...still used old MIME types, like "UTF8_STRING", "text/unicode", "TEXT" and "COMPOUND_TEXT". But at the same time, they provided a text/plain... but it was empty! Not useful anymore for Firefox,=20 I do not have GEdit installed anymore (and SuSE CDs are not wher I am now= ). =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Then, there is NoteFactory: ------------------------------------------------------------- The following methods: NoteFactory::createNoteText NoteFactory::createNoteHtml NoteFactory::createNoteLink NoteFactory::createNoteImage NoteFactory::createNoteColor NoteFactory::createNoteLauncher NoteFactory::createNoteUnknown create single notes from a content, they create the associated file if need= ed. NoteFactory::createNoteLauncher need NoteFactory::createNoteLauncherFile to= =20 create and fill the file. ------------------------------------------------------------- NoteFactory::dropNote do the whole work to drop or paste something. It detects the type of what's dragged/copied. It begin to threat the most obvious formats, and then, if there is ambiguit= y,=20 it tries to auto-detect formats and paste things accordingly: * If a note was dragged, it calls NoteDrag::decode to do the hard work (move the notes to a new position, a new basket, or copy them...). * If a pixmap was dragged, it paste it by procedding as needed. * Same if it was a color. * Idem for a list of URLs, but with some details: - A special attention goes to dragging a link from Firefox, or a list of bookmark links... "text/uri-list" is not provided, but the custom "text/x-moz-url", that also provide a title for each link. Those Mozilla URLs are then threated as normal URL list, as described bellow. - If we're dropping URLs, this can be either file URLs, so we should copy/move the files to the baskets and create teh associated file notes. Or HTTP URLs, in this case, we create link notes. This is managed by NoteFactory::dropURLs: # First, if it's a DROP and no modifier key is pressed AND there are dragged local files, it should popup a menu for the user to choose = an action between copy/move/link. # Then, for each link, it tries to detect the type of the linked file and create a note of that type. If it does not success, it crate a link note: ~ Email address =3D> Create a link note ~ Remote URL =3D> - Download as Image, Animation and Launcher notes if possible and it sea= ms the URLs are pointing to such objects - Create a link note for other URLs ~ Local URLs while DROPPING =3D> - Copy as Image, Animation and Launcher notes if possible and it seams the URLs are pointing to such objects - Create a link note if the URL is a folder URL - Make Launcher of URLs to executables - Copy/Move/Link the file or sound note, depending on the pressed modifi= er keys or the response to the popup menu by the user. ~ Locale URLs while PASTING =3D> - Same as drops but copy when asking (popup menu) should be done - Unless the MIME type cut-selection is true: move files instead * Then comes "text/html", where it is simple for most cases, but not for Firefox, that encode it as UTF16. We use the ExtendedTextDrag class for that. * If we haven't found a matching MIME type, the very hard work comes: decod= ing texts! This text decoding try to be smart and to recognize plain text and HTML, but also colors, urls, email addresses (with or without attached name). For that, NoteFactory::createNoteFromText is called. It manage teh following smart detections: - Color hexadecimal format - URLs if NoteFactory::textToURLList success to detect that all the text = is a list of (or only one) URL. We threat this URL list as if it was a text/uri-list MIME type. See above (NoteFactory::dropURLs). If at least one line is not a URL or an email address (either of the fo= rm "na...@do..." or "Name <na...@do...>", then NoteFactory::textToURLList fail and return an empty list: we know they aren't URLs, they are plain or rich text. - Html if maybeRichText returns true - Text to Html convertion if it is a plain text (in last ressort) * At the very least ressort, dropNote() create a note of type Unknown and paste the MIME type AS IS, so it can be dragged back to an application th= at understand that MIME type. Best regards, S=E9bastien Lao=FBt. |
From: <sl...@li...> - 2006-09-09 14:13:00
|
Le Mardi 5 Septembre 2006 01:10, Alex Gontmakher a =E9crit=A0: > > > What is "Mouais"? > > > > A french equivalent to "Hum... yep" / "Hum... yes" ;-) > > Without being that convinced. > > Good word. Will learn. Is it slang or a normal word from dictionary? And > how is it pronounced? It's not in the dictionnary. It's a contraction of "Hum Ouais", where "Ouais" is an oral-only word for=20 "Yes" ("Oui" in French). "Ouais" is not considered as very polite, but used a lot by people. > Well, I actually like how it consists of independent notes. For example, = an > important use case for me is dragging notes from one basket to another > (think TODO lists). Oh, and I do not reny the importance of independant notes! Without them, BasKet Note Pads would "just" be a poor copy of OneNote. Independant notes are what missed me a lot when I tryed OneNote: it's a big= =20 mess to find something when things are not splitted in different=20 easily-recognizable notes. But this note-separation comes with some little drawbacks. Especially when editing, it introduce modes, and people are trained with th= e=20 document concept. So my idea is to keep the bright independant-notes idea, but also implement= =20 the one-document concept to make other people happy, but also to ease the=20 editing of notes, lower the need to several modes (a usability nightmare) f= or=20 most common use-cases. > No, I think I do understand you. However, implementing that will not be a > picknick, since each editor implements history of its own - and you don't > want to reimplement text editor's Undo/Redo functionality! Well, I always prefered an easy-to-use applicaiton instead of an easy-to-co= de=20 application: most people will only use it, only 3 will code it, so make it= =20 easy for the majority. And I do not think it will be such a mess. Yes, we will connect our Undo/Redo implementation to the undoChaned" signal= of=20 the editor and manage Undo/Redo by ourself, but that's the way to go. Undo/redo is to make people able to do error. They should be able to make=20 error anywhen, and be able to recover from them anywhene, not only while th= e=20 editor is closed and it's too late. One Undo/Redo per basket and another one per editor introduce yet another=20 mode, which is very bad from a usability viewpoint. And it's one more thing people will have to learn to use: several Undo/Redo. Would make the use of BasKet Note Pads much more difficult. To conclude, one Undo/Redo per basket only is the easier thing for the user= s,=20 the thing they do expect, even if that means more code, it will result in=20 more people using the application, and more happy users. > There is one important thing in this respect. I'm thinking to try the > following feature: a cut marker in the note. It should work in the > following way: > > - when you're editing a note, a little sash sits in the top-right corner = of > the editor. You can drag it down. > - when you finish editing the note, its displayed size is limited by the > new position of the sash. > > This can be very useful. For instance, if a note has a title (or maybe a > subtitle as well), you want only the title to be displayed, and to see the > whole text only when you're interested in it. In addition, if the note is= a > picture, it will be scaled down accordingly, making the navigation easier. > > The same effect can be achieved to a certain extent by grouping notes. But > grouping is not as convenient - you'll have to create a note for the titl= e, > then a note for the contents, then group them together, and then close the > group. And if you want to display slightly more or less, you'll have to > move text between the notes... Hum yep... Go for it. I think it will rarely be used. It's better if the size is automatically managed by the application (anothe= r=20 advantage of BasKet Note Pads over OneNote: use of columns, and automatical= ly=20 placed notes, a LOOOOOOT easier than the mess introduced by free-layout=20 notepads/baskets where users should constantly deal with boring placing=20 tasks). To make it clear: Some users asked to be able to resize down images, and other asked to=20 I consider this feature to be used SELDOMLY, but ABSOLUTELY needed in those= =20 seldom cases. So it SHOULD be done: thanks if you implement it. But while doing it, just keep in mind this will not be used proeminently. =46or instance, baskets should default to automatically-sized notes, to not= =20 annoy users. Or users could resize a note by error: it should be easy to co= me=20 back to the auto-sizing behaviour. =46or instance, in OneNote, text notes expands horizontally AS NEEDED. But = you=20 can resize them as you want. Nice! I appreciate that. BUT AS SOON AS you sized a note manually by error or for temporary need, it= =20 will NEVER goes back to automatically-sized behaviour. This pissed me a lot. That's all: just keep in mind this limitation and I will happily include yo= ur=20 manual-sizing of notes. You will make lot of people happy with this new feature! > This could interfere with your continuous editing idea... Ok, maybe not, > but it would make navigation rather jumpy. As long as this is activated only for the rare-cases when user WANT it to, = it=20 will be only a benefit! But when users do not want a custom size for a note, it should default to t= he=20 continuous editing concept. > Yeah, but what about edit history in different baskets? Do you want to ke= ep > that linear as well? Oh, of course there is one history PER BASKET. The same that there is one history per Kate document, and many other=20 applications. > > > > That begin to be a lot of things to do for KDE 4!!! > > > > > > Yeah, that begins to bother me too. > > > > Something possible is to quickly move to KDE 4. > > I would only add minimal new features into 0.6.X version(s). > > And then we quickly port that to KDE 4. > > And then everything will be easier, and everything will be to code once > > again, the right way, this time. > > I'd like to, but isn't that too optimistic? KDE4 is far off yet... unless > there will be a way to run selected KDE4 applications in parallel with a > complete KDE3 desktop. A KDE 4 snapshot has been released. Most (if not all) KDE applications are now compiling. They are working again like in KDE 3. In october, for aKademy, there will be a public release, I expect it to be= =20 somewhat usable (like KDE3 is usable now, not like KDE4 is planned to be=20 feature-wise). By the time, 0.6.0 will be soon to be released. So at this time it can be realistic to start porting to KDE4, IMHO. Best regards, S=E9bastien Lao=FBt. |
From: <sl...@li...> - 2006-09-09 13:47:25
|
Le Mardi 5 Septembre 2006 00:24, Alex Gontmakher a =E9crit=A0: > On Tuesday 05 September 2006 01:08, S=E9bastien Lao=FBt wrote: > > Well... I compiled your branch, and I can't paste HTML from Konqueror. > > Or does it only work on you computer? > > Can you commit? > > That's strange, it works for me. I've committed now all the changes there, > although it shouldn't affect this feature. I've just tried, and it worked > OK (Note that I have KDE 3.5.4 - maybe this is different?) Ah, it was my fault, sorry! Using this command: LD_LIBRARY_PATH=3D./.libs/ ./.libs/basket --nofork in src/ folder works better :-D BTW, nice improvements! Yes, HTML pasting works. I just have a small bug is sizing. See attached screenshot. And when I place my mouse pointer on the epty-area on the bottom, the=20 insertion-line is shown on top of the note I'm editing in the screenshot, a= nd=20 not at the bottom of the basket. But you are perhase aware of them. How to resize horizontally? And then, when is that useful? > > - Where is the code to handle pasting of HTML from Konqueror? > > There's none, that's the beauty of it :) > > Well, the code is in NoteFactory::dropNote() - there are two > calls "decodeHtml" and "decodeText". But there is nothing specific for > Konqueror, as it provides text/html in its d&d protocol. Yes, that's beautiful. Best regards, S=E9bastien Lao=FBt. |
From: <sl...@li...> - 2006-09-09 13:34:57
|
Le Mardi 5 Septembre 2006 11:38, Alex Gontmakher a =E9crit=A0: > I think that I need to refactor BNPView to implement some things (what I > want to do is that if you drag a note to a basket in the basket list pane > and drop it quickly, the note will be moved to the corresponding basket. = If > you hover on the basket, the current basket will still switch to the new > one, and then you'll be able to drop in the basket window as well). Yes, a highly requested feature. It was present in 0.5.0 but I don't know WHY it is buggy in 0.6.0. I tryed to implement it in 0.6.0 but without success. > The refactoring I want to do: > 1. Create a class BasketListView that inherits from KListView and use it = in > the BNPView > 2. (not necessary for the change I want, but very natural). Move all the > relevant functionality (lots of stuff...) from BNPView to BasketListView. Yes, this is the way to go. But not in 0.6.0 as it will be lot of refactoring. Tought: 1. "class BasketTreeListView : public KListView" is already there. But you are right: the whole logic need to be migrated there. However, I would wait for KDE 4 List/View/Controler patern to refactor it o= nce=20 and for all, in the right way! I previously talked about how startup time coule be improved. Don't remember if it was with you or not. So, basically: Currently, when the app starts, it load the basket hierarchy and create a=20 Basket instance for every baskets (a BasketDecoration, to be more precise).= =20 This instances creation take a lot of time, because it have to create lot o= f=20 objects, and communicate a lot with the X server to create every widgets (t= he=20 scrollview, the filterbar, the filter buttons)... the filter-tag combobox h= as=20 to be populated... etc. What I would want to do is that on startup we should load the basket hierar= chy=20 MODEL, and that's all. No more. Then, when a user will open a basket, the whole basket will be loaded: the= =20 widgets will be created, and the content loaded (that last point is already= =20 done). Proof that it will make the aplication to startup at the light speed: =2D Rename your ~/.kde/apps/basket folder, launch BasKet: it starts in ONE= =20 second. =2D Put back your basket data folder, with 30 to 50 baskets: it take TWO se= conds=20 to startup! 100% more! With the Model/View/Controler architecture of Qt4: =2D Only one class will contain the basket hierarchy =2D We will ONLY load the hierarchy on startup, and load baskets on demand =2D Other possibilities will be offered to us The other possibilities are: =2D In the "Basket/New..." dialog, a little combobox shows the hierarchy of= =20 baskets. This is currently done by browsing the KListView. We should use the MODEL instead. =2D I would want to implement a dialog "Basket/Move to..." that shows let p= eople=20 move the current basket to another parent. This is for people who do not kn= ow=20 about drag and drop: how should they move a basket to another parent, on to= p=20 of the hierarchy, below another basket... ? People who do not know drag and= =20 drop cannot and are handicapped in this area! So the new dialog will show a hierarchy, the user will select one basket an= d=20 then click one of the following buttons: [ Move Into ] [ Move Below ] [ Move Above ] [ Cancel ] > I'll do that in a branch, not sure it's safe enough for 0.6... I don't think so. > Any objections? Wait for Qt4 model/view/controler? So the refactoring will have to be done only once, instead of now and then = for=20 KDE4! But "drag notes to a basket name" can be done now, without deep refactoring. Perhapse you will have more luck than me: I added std::cout debugs to the=20 custom KListView, but it doesn't work. I'm sure it's only a few lines of code to change to make it work. So, that's one more reason why I now would want to migrate to KDE4 soon. Best regards, S=E9bastien Lao=FBt. |
From: <sl...@li...> - 2006-09-09 13:16:29
|
Oh, and one more thing: If you want to work on bufferization code, then there is the basket TreeViewItems to bufferize! With the whole treeview full of baskets, the drawing of it take litteraly one second with free-ATI drivers! It's enormous! Haven't tryed with proprietary NVidia drivers of my new computers, but that's not acceptable it's so slow for freedom-attached users. Basically, to draw the rounded basket-colored-names, I create a picture for each name that is twice or 3x time the size of the basket name, then draw and reduce the picture so it is smoothly antialiased. Same for the filter-count. Try do a global filter for " ", minimize the BasKet window and re-show the window: it will take 1 to 2 seconds depending on your video drivers. While the basket repaint will be instantaneous, you the see the basket repainting. What's to be changed is to have ONE buffer PER TREE-VIEW-ITEM, and only repaint that item when it has changed: - When the basket properties (name, color, background color, icon) has changed - When the filter count has changed - When it is opened/closed - When the basket is activated/closed - When the basket below or above it is activated/closed (to paint the tabs-like blue rounding on the right) And make sure the buffer is refreshed always and only in those circumstances. If you can do it, I will include in 0.6.0! It's so important that I will take the risk of introduce it even if buggy. Why so important? Try filtering all baskets with the baskettree full of baskets. Each time the count for a basket is changed, the whole tree is repainted, so the tree is repainted a lot of times in a few seconds. I haven't done it because as an alone programer I have more important things to fix before. But that would ROCK! With that fix done, the application will be lightening fast! |
From: <sl...@li...> - 2006-09-09 13:06:40
|
Le Vendredi 8 Septembre 2006 01:58, Alex Gontmakher a =E9crit=A0: > Well, I just removed all the smart code that handles the painting of the > blank regions in the Basket, instead added some naive double-buffering (t= he > only trick there is to keep the pixmap persistent, allocating and > deallocating it every time is too expensive). > > Works just fine - same as it did before, and the code is much more dumb > now :). Must still add some smarter handling for the double buffering > pixmap (maybe have one shared for all the baskets... or having it deleted > when the basket goes out of focus...) to save memory, but that'll be easy. If I understand you well, it's drawing the whole basket into a big picture,= so=20 that we when we hide the basket and show it again, it's snappy. But is it really needed? =2D Every single note is already double-bufferised. Mainly for animation=20 purpose. =2D Colored background is paint in one shot by filling rectangles wil plain= =20 color. =2D And semi-transparent background images are already cached so that no=20 transparency computation is to be done only once, and afterward, it's all=20 about painting pixmaps on screeen byte per byte. Really fast. If I do not misunderstood, this global buffer is slowering the drawing=20 because: =2D For each frame of the animation, notes... have to be drawn to the globa= l=20 buffer and then the buffer is drawn on screen =2D But that also means on each frame, the notes draws are not from the not= e=20 buffer, but each note should be re-drawn one more time. Really slow. =2D Modern X11 systems (Xgl, aXgl, Compiz and co.) already have a persitent= =20 back-store per window, so it's one more layer of bufferization, making your= s=20 useless. If I'm right, and you removed every double-buffers to replace them all by a= =20 big buffer per basket, then I will explain to you all the little tricks tha= t=20 are made to make the drawing as fast as possible. They are numerous and not that easy to understand, but it's the solution I= =20 came up that give the best results, best caching, and reduce as many redraw= =20 as possible. I've done the code while my graphics acceleration was not working, without = any=20 graphics card driver. The first Make-it-Cool versions were not that fast, b= ut=20 weeks after weeks, as I added ever fine-tuning tricks, it became fast, even= =20 with baskets with background images. Before the optimisations, I tought to= =20 removed the background images feature. But not anymore. Oh, and why is the following line removed (basket.cpp, ~line 570): recomputeBlankRects(); // FIXME: called too much time. It's here because wh= en=20 dragging and moving a note to another basket and then go back to the origin= al=20 basket, the note is deleted but the note rect is not painter anymore. > I also want to try to remove the corresponding smartness from the Notes - > just let them paint whatever they want and let the double buffering handle > the smoothness. Looks like it's going to work just as well. So, you will remove the buffering of every notes, and replace them by one b= ig=20 Animations will suffer from it, especially for baskets with big background= =20 pixmaps. > Still, if you have any serious reasons to keep the code the way it's done > now, or any particular fondness for your empty area computations, let me > know (so far, I just deleted it mercilessly). Please explain what you were wanting to achieve. Then we will see if it's the right way to go. Ah, so you removed the empty-area computation?! So you draw everything off-screen, even if that means drawing some pixels=20 several times?! Hum... bad. I know the empty-areas are hard to understand, but it's efficient. Oh, and let me know if I'm wrong and totally misunderstood your changes ;-) > I've also refactored the code of the animation into a separate class call= ed > Animator. Haven't integrated it yet, but I wrote a small test for it, > called basket_animator_test. You can play with it, checking different > parameters of the animation - I've finally found the parameters that look > best to me, but you can experiment... Again: why, and for what benefit? And how? The diffs are now 1200+ lines of code, so I have a little hard time underst= and=20 everything :-/ > And now other good news. I got too confused trying to build the test with > autotools (I HATE THEM!!!!!!!! I HATE THEM!!!!!!! I HATE THEM!!!!!!), so I > just went out and wrote a cmake build for them. And guess what? It was > easy, and it works great! It's so much faster than auto* that it hurts. > You'll need to install the latest cmake (2.4.3), and otherwise, just go to > some directory you like and run: > > cmake <path to basket/src - it'll be looking for file "CMakelists.txt"> > make > ./basket_animator_test Nice. But I think I will apply my sentence "when it works, don't touch" and keep= =20 autotools for KDE 3. Is cmake integrated into KDevelop? Does KDevelop still knows the list of files in the projects so that=20 Ctrl+Shift+O works again? Do you have detected libGPGme and libgpg-error? Do you have detected libkdepim? Does it displays a nice message to users, at configure time, to tell them w= hat=20 packages to install (see file configure.in.bot). All in all, it's a nice news we have someone who knows Cmake when we will=20 migrate to KDE4. Then it WILL be included. > Just click somewhere inside the window to see the animation. Now, it > repaints all the screen every time, so the speed should be about the same > if you move one rectangle or 100, as long as their total area is about the > same as that of the viewport. Seems I do not have CMake. Yast2 do not find packages for it. I will not loss time trying to install it on SuSe since I will migrate to m= y=20 new Kubuntu-based computer soon. Will test it when I have fully migrated to Kubuntu, understood that system = and=20 fixed the bugs apt-get give me (hum yeah... I took the BETA version of=20 KUbuntu, so I have wired behaviours). So, what is the point of the new Animator? Exactly the same as before? Then... "it works, so don't touch" applies. Best regards, S=E9bastien Lao=FBt. |
From: Alex G. <gs...@cs...> - 2006-09-07 23:58:20
|
Hi Sebastien, I've done a bit - in my branch. It's not complete, but is working, and that's what branches are for... :) Well, I just removed all the smart code that handles the painting of the blank regions in the Basket, instead added some naive double-buffering (the only trick there is to keep the pixmap persistent, allocating and deallocating it every time is too expensive). Works just fine - same as it did before, and the code is much more dumb now :). Must still add some smarter handling for the double buffering pixmap (maybe have one shared for all the baskets... or having it deleted when the basket goes out of focus...) to save memory, but that'll be easy. I also want to try to remove the corresponding smartness from the Notes - just let them paint whatever they want and let the double buffering handle the smoothness. Looks like it's going to work just as well. Still, if you have any serious reasons to keep the code the way it's done now, or any particular fondness for your empty area computations, let me know (so far, I just deleted it mercilessly). I've also refactored the code of the animation into a separate class called Animator. Haven't integrated it yet, but I wrote a small test for it, called basket_animator_test. You can play with it, checking different parameters of the animation - I've finally found the parameters that look best to me, but you can experiment... And now other good news. I got too confused trying to build the test with autotools (I HATE THEM!!!!!!!! I HATE THEM!!!!!!! I HATE THEM!!!!!!), so I just went out and wrote a cmake build for them. And guess what? It was easy, and it works great! It's so much faster than auto* that it hurts. You'll need to install the latest cmake (2.4.3), and otherwise, just go to some directory you like and run: cmake <path to basket/src - it'll be looking for file "CMakelists.txt"> make ./basket_animator_test Just click somewhere inside the window to see the animation. Now, it repaints all the screen every time, so the speed should be about the same if you move one rectangle or 100, as long as their total area is about the same as that of the viewport. Enjoy. Comments welcome. Regards, Alex |
From: Alex G. <gs...@cs...> - 2006-09-05 09:38:48
|
Hi, I think that I need to refactor BNPView to implement some things (what I want to do is that if you drag a note to a basket in the basket list pane and drop it quickly, the note will be moved to the corresponding basket. If you hover on the basket, the current basket will still switch to the new one, and then you'll be able to drop in the basket window as well). The refactoring I want to do: 1. Create a class BasketListView that inherits from KListView and use it in the BNPView 2. (not necessary for the change I want, but very natural). Move all the relevant functionality (lots of stuff...) from BNPView to BasketListView. I'll do that in a branch, not sure it's safe enough for 0.6... Any objections? Regards, Alex |
From: Alex G. <gs...@cs...> - 2006-09-04 23:10:52
|
> > What is "Mouais"? > > A french equivalent to "Hum... yep" / "Hum... yes" ;-) > Without being that convinced. Good word. Will learn. Is it slang or a normal word from dictionary? And how is it pronounced? > The initial staring point for BasKet Note Pads was somewhat wrong: > delimiting every notes into "items" is not both good and bad. > > * It's good because it allows to "group" two non-related clip of texts. > If I have two notes of several lines each, I know that I have two ideas in > my basket. Having no "note/item" separation is worst: you have a big > paragraph and do not know that they are representing two ideas, of two > clips of text... > > * It's limitating because people want to mix formated text, images, > links... all in one note. They want to insert images into rich text > notes... but also links... because it is representing one idea (the oposite > of the first point). Well, I actually like how it consists of independent notes. For example, an important use case for me is dragging notes from one basket to another (think TODO lists). > > Well, I perapse haven't well explained what I have in mind, but it's late: > feel free to ask questions. I'm going to bed for now. No, I think I do understand you. However, implementing that will not be a picknick, since each editor implements history of its own - and you don't want to reimplement text editor's Undo/Redo functionality! There is one important thing in this respect. I'm thinking to try the following feature: a cut marker in the note. It should work in the following way: - when you're editing a note, a little sash sits in the top-right corner of the editor. You can drag it down. - when you finish editing the note, its displayed size is limited by the new position of the sash. This can be very useful. For instance, if a note has a title (or maybe a subtitle as well), you want only the title to be displayed, and to see the whole text only when you're interested in it. In addition, if the note is a picture, it will be scaled down accordingly, making the navigation easier. The same effect can be achieved to a certain extent by grouping notes. But grouping is not as convenient - you'll have to create a note for the title, then a note for the contents, then group them together, and then close the group. And if you want to display slightly more or less, you'll have to move text between the notes... This could interfere with your continuous editing idea... Ok, maybe not, but it would make navigation rather jumpy. > > So, to finalyy reply undo/redo problem of above: > Basically, boundaries between "editors" and notes should become less > important. "Editors" should only be a developer-centric view. > Users will see "one document", the basket, and the cursor can be placed > anywhere on that basket. > So, in that way, it's logical to the user that pressing Undo will revert > "B:text4" to "B:text2", even if from the programmer point of view, he is > editing note 1: the last action of the user ON THAT DOCUMENT was to change > note B. Yeah, but what about edit history in different baskets? Do you want to keep that linear as well? > > > > That begin to be a lot of things to do for KDE 4!!! > > > > Yeah, that begins to bother me too. > > Something possible is to quickly move to KDE 4. > I would only add minimal new features into 0.6.X version(s). > And then we quickly port that to KDE 4. > And then everything will be easier, and everything will be to code once > again, the right way, this time. I'd like to, but isn't that too optimistic? KDE4 is far off yet... unless there will be a way to run selected KDE4 applications in parallel with a complete KDE3 desktop. |
From: Alex G. <gs...@cs...> - 2006-09-04 22:25:05
|
On Tuesday 05 September 2006 01:08, S=E9bastien Lao=FBt wrote: > Well... I compiled your branch, and I can't paste HTML from Konqueror. > Or does it only work on you computer? > Can you commit? That's strange, it works for me. I've committed now all the changes there,= =20 although it shouldn't affect this feature. I've just tried, and it worked O= K=20 (Note that I have KDE 3.5.4 - maybe this is different?) How to do it: 1. select text in Konqueror, press Ctrl+C 2. go to basket, press Ctrl+V: text is inserted as rich text 3. go to basket, open a note for editing, press Ctrl+V: the HTML source is= =20 inserted as plain text :(. I haven't yet found a way to do that properly :( > > I ran BasKet with the following command: > LD_LIBRARY_PATH=3D./.libs/ basket --nofork > Should do the trick but perhase it has used the installed version of the Well, do make sure. > library. Will have a look at it tomorrow (yes... that begin to be > ridiculous all those tomorrow... today I finaly bought the new computer, > and begin some migration). > > I also read and tryed to understand the diffs. > > Some questions araise: > > - What is the text editor debug window? > From the diffs, it seems to only echo the text content to the debug > window. No, it shows the HTML source - which might be useful if you think that the= =20 editor is behaving suspiciously. > > - Where is the code to handle pasting of HTML from Konqueror? There's none, that's the beauty of it :) Well, the code is in NoteFactory::dropNote() - there are two=20 calls "decodeHtml" and "decodeText". But there is nothing specific for=20 Konqueror, as it provides text/html in its d&d protocol. > > - Where is the code to handle pasting HTML into the QTextEdit? Same |
From: <sl...@li...> - 2006-09-04 22:24:02
|
Le Mardi 5 Septembre 2006 00:01, Alex Gontmakher a =E9crit=A0: > > Mouais... Somewhat limited. > > What is "Mouais"? A french equivalent to "Hum... yep" / "Hum... yes" ;-) Without being that convinced. > Problem is, there is no easy way to add a global Undo that would handle t= he > whole history. Consider: > > - you have a basket with two notes, containing "A:text1" and "B:text2" > - you now edit the first note to contain "A:text3" > - you now edit the second note to contain "B:text4" > - you now close the second note and go back to editing the first one. > - you press "undo". What do you think should happen? IMHO, it's either the > return to "A:text1" or nothing. All other options would mightily confuse > the user (and all other options would require us to manually implement un= do > for text editing, which would be a lot of work!) > > So, I think that the Undo framework should look like this: > 1. When you're editing a note, the Undo history is local, i.e., it can on= ly > restore the changes from the current editing session > 2. When you finish an editing session, the Undo information that will be > kept is the state before the session > 3. To make that more intuitive, we can have two levels of Undo buttons, o= ne > in the Edit menu, and another that will appear when you open a note for > editing. Note that this is more or less the behavior of Kontact except th= at > it doesn't have inline editing for mails. > > Thinking of which, it might be a good idea to add an option of opening a > note for editing in its own window. Oh, dunno, that might be an overkill - > comments? The initial staring point for BasKet Note Pads was somewhat wrong: delimiti= ng=20 every notes into "items" is not both good and bad. * It's good because it allows to "group" two non-related clip of texts. If I have two notes of several lines each, I know that I have two ideas in = my=20 basket. Having no "note/item" separation is worst: you have a big paragraph= =20 and do not know that they are representing two ideas, of two clips of text.= =2E. * It's limitating because people want to mix formated text, images, links..= =2E=20 all in one note. They want to insert images into rich text notes... but als= o=20 links... because it is representing one idea (the oposite of the first=20 point). I want to keep the "one note per idea" concept. But I would want to empower users to add images to text notes, to add title= d=20 links... That's only a rough idea in my head, but little by little it takes form. The main thing to remember is that for the user, a basket is a document, ON= E=20 document. And everywhere else, Undo is undoing things on the whole document. More and more, I would want to blur the separation with notes and "a=20 document". I've done that by not forcing people to close the editors. I would want that the arrow keys to browse between notes. =46or instance: =2D------------------- Note 1 with| <-- My cursor is here, I'm editing note 1. two lines of text. =2D------------------- Note 2 with two lines of text. =2D------------------- Pressing bottom conduce to that situation: =2D------------------- Note 1 with two lines o|f text. =2D------------------- Note 2 with two lines of text. =2D------------------- Normal. But pressing Bottom one more time should (in the future) conduce to= =20 that situation: =2D------------------- Note 1 with two lines of text. =2D------------------- Note 2 with| two lines of text. =2D------------------- Editor 1 is closed, note 2 is now edited and the cursor is logically placed. As expected, this is transparent for users. We keep the benefit of different notes: keep boundaries between two ideas=20 (note 1 and note 2), but have the facility/efficiency of "one document": "t= he=20 basket". Well, I perapse haven't well explained what I have in mind, but it's late:= =20 feel free to ask questions. I'm going to bed for now. So, to finalyy reply undo/redo problem of above: Basically, boundaries between "editors" and notes should become less=20 important. "Editors" should only be a developer-centric view. Users will see "one document", the basket, and the cursor can be placed=20 anywhere on that basket. So, in that way, it's logical to the user that pressing Undo will revert=20 "B:text4" to "B:text2", even if from the programmer point of view, he is=20 editing note 1: the last action of the user ON THAT DOCUMENT was to change= =20 note B. > > That begin to be a lot of things to do for KDE 4!!! > > Yeah, that begins to bother me too. Something possible is to quickly move to KDE 4. I would only add minimal new features into 0.6.X version(s). And then we quickly port that to KDE 4. And then everything will be easier, and everything will be to code once aga= in,=20 the right way, this time. |
From: <sl...@li...> - 2006-09-04 22:08:28
|
Well... I compiled your branch, and I can't paste HTML from Konqueror. Or does it only work on you computer? Can you commit? I ran BasKet with the following command: LD_LIBRARY_PATH=./.libs/ basket --nofork Should do the trick but perhase it has used the installed version of the library. Will have a look at it tomorrow (yes... that begin to be ridiculous all those tomorrow... today I finaly bought the new computer, and begin some migration). I also read and tryed to understand the diffs. Some questions araise: - What is the text editor debug window? From the diffs, it seems to only echo the text content to the debug window. - Where is the code to handle pasting of HTML from Konqueror? - Where is the code to handle pasting HTML into the QTextEdit? So, tomorrow, I will document my code here and explain my "hacks". |
From: Alex G. <gs...@cs...> - 2006-09-04 22:01:18
|
> Mouais... Somewhat limited. What is "Mouais"? > I wonder if people will strt complaining Undo/Redo are not working when not > editing, or not working at all (because in there mind Undo/Redo is for > everything, always available, and not available for some seconds). > > But it's better than nothing, you're right. > Let's try to include it in the next beta. > > The plan for KDE 4 is to use the Qt 4 history framework, and Undo/Redo will > be available for the whole basket, undoing/redoing note > addition/deletion/moves AS WELL as keystrokes in QTextEdit, all of that > transparently for the user. Problem is, there is no easy way to add a global Undo that would handle the whole history. Consider: - you have a basket with two notes, containing "A:text1" and "B:text2" - you now edit the first note to contain "A:text3" - you now edit the second note to contain "B:text4" - you now close the second note and go back to editing the first one. - you press "undo". What do you think should happen? IMHO, it's either the return to "A:text1" or nothing. All other options would mightily confuse the user (and all other options would require us to manually implement undo for text editing, which would be a lot of work!) So, I think that the Undo framework should look like this: 1. When you're editing a note, the Undo history is local, i.e., it can only restore the changes from the current editing session 2. When you finish an editing session, the Undo information that will be kept is the state before the session 3. To make that more intuitive, we can have two levels of Undo buttons, one in the Edit menu, and another that will appear when you open a note for editing. Note that this is more or less the behavior of Kontact except that it doesn't have inline editing for mails. Thinking of which, it might be a good idea to add an option of opening a note for editing in its own window. Oh, dunno, that might be an overkill - comments? > > That begin to be a lot of things to do for KDE 4!!! Yeah, that begins to bother me too. |
From: <sl...@li...> - 2006-09-04 19:41:03
|
Le Lundi 4 Septembre 2006 18:53, Alex Gontmakher a =E9crit=A0: > Ok, now I've committed a change that answers 5 likeback comments. > Now what I would like to do is: > 1. somehow group these comments for future reference > 2. hide them!!! > > Didn't find anything to that effect on the page. Any ideas? 1. Not currently possible. But in the future, it will be possible to mark comments as duplicate of other ones, and review all duplicate comments at once. 2. You can click the status icon (the File/New icon) and it will popup a me= nu: Mark comments as fixed or invalid, and it will be hidden (unless you fil= ter for such comments). |
From: <sl...@li...> - 2006-09-04 19:36:41
|
Grrr. Why is KMail so buggy?!!!!!! Re-expeding the mail to the list! Le Lundi 4 Septembre 2006 18:52, Alex Gontmakher a =E9crit=A0: > There's now undo/redo buttons when you open a note for editing (well, the > undo was always available there, through C-Z shortcut...). It's not > complete of course, the full implementation will be done when we have Qt4. > The history is cleared when you close the note editor, but still, this is > better than nothing. > > I've committed it to HEAD. Please take a look. Mouais... Somewhat limited. I wonder if people will strt complaining Undo/Redo are not working when not= =20 editing, or not working at all (because in there mind Undo/Redo is for=20 everything, always available, and not available for some seconds). But it's better than nothing, you're right. Let's try to include it in the next beta. The plan for KDE 4 is to use the Qt 4 history framework, and Undo/Redo will= be=20 available for the whole basket, undoing/redoing note addition/deletion/move= s=20 AS WELL as keystrokes in QTextEdit, all of that transparently for the user. That begin to be a lot of things to do for KDE 4!!! |
From: Alex G. <gs...@cs...> - 2006-09-04 16:54:41
|
Ok, now I've committed a change that answers 5 likeback comments. Now what I would like to do is: 1. somehow group these comments for future reference 2. hide them!!! Didn't find anything to that effect on the page. Any ideas? Regards, Alex |
From: Alex G. <gs...@cs...> - 2006-09-04 16:52:51
|
There's now undo/redo buttons when you open a note for editing (well, the undo was always available there, through C-Z shortcut...). It's not complete of course, the full implementation will be done when we have Qt4. The history is cleared when you close the note editor, but still, this is better than nothing. I've committed it to HEAD. Please take a look. Regards, Alex |
From: Alex G. <gs...@cs...> - 2006-09-03 22:04:56
|
On Monday 04 September 2006 00:55, S=E9bastien Lao=FBt wrote: > Ah, I just reinstalled DndSkan and tryed from Konqueror: they finally > implemented text/html dragging in KHTML! Opera still doesn't... > Houraz. > > The only hick: BasKet Note Pads SHOULD detect HTML flavour. > But it doesn't. You mean that it should detect the fact that it's HTML and import it as ric= h=20 text? If so, then yep, I did that for whole notes, but unfortunately, there= 's=20 no way to insert HTML into an open QTextEdit (apart from fabricating a=20 q-richtext...) :( > > Perhapse it's due to the DOCTYPE or the xHTML... > Will have a look at this. > I'm sure it's a very small change to do. No, the problem was that the existing code (before I did my deed) was=20 forcefully converting everything into plain text. I just canceled that :)=20 Also, my code prefers taking various Unicode encodings since they are more= =20 general. All in all, I haven't seen a situation in which it didn't work. P.S. Don't be too quick to merge it into HEAD yet, though. There are some=20 preliminary things, like that text/plain imports currently as a <pre></pre>= -=20 looks great for code, but must be made optional. |
From: Alex G. <gs...@cs...> - 2006-09-03 21:55:37
|
> I finally found an interesting computer: I will pehapse have it this week > or weekend. > FINALLY, hard drive space will not be a problem (I'm always running at 100 > or 0 Mo free, so I must spend time to move/remove data), the NVidia driver > will work, and everything will be accelerated (currently the computer is so > slow because of no graphics driver), etc. > So at the end of the week, don't expect me to be very active: I will switch > all my data to the new computer, reinstall everything, etc. Good. Take your time, make it well organized so that you don't waste time on it later :) |
From: <sl...@li...> - 2006-09-03 21:55:14
|
Ah, I just reinstalled DndSkan and tryed from Konqueror: they finally implemented text/html dragging in KHTML! Houraz. The only hick: BasKet Note Pads SHOULD detect HTML flavour. But it doesn't. Perhapse it's due to the DOCTYPE or the xHTML... Will have a look at this. I'm sure it's a very small change to do. Oh, and perhapse you've solved it in your branch. Should have a look at it too :-) |
From: Alex G. <gs...@cs...> - 2006-09-03 21:47:37
|
> It's the expected behaviour: pressing Enter should create a new line, not a > new line with some superfluous margin (a paragraph)! > > You still can insert new lines instead of paragraphs by pressing Ctrl+Enter > or Shift+Enter. Then the justification will work. I see - but please note that it's counterintuitive: in any wordprocessor I care about, Enter starts a new para and Shift+Enter inserts a line break, just the opposite of Basket. > > I won't revert that "hack" until paragraphs have even one pixel of margin. > Adding new lines to notes is a VERY frenquent usecase. > If every new lines were creating so much margins, the note windows would > take too much space. Too little information would be shown at once. I see. However recall, I recently proposed having two variants of paste: paste as richtext, paste as plain text and pase as code. The difference between the first one and the last two could be exactly that: in richtext, it will always be paragraphs, and in plain text/code it will be line breaks. Please? > > I'm sure it will be possible in Qt4 (not tested, but the trolls should have > done that, through QTextParagraph or whatever it's named). > So it will be changed in KDE 4. Let's write that down prominently to make sure it's not forgotten. > > Too much hacks for something that will be changed in KDE 4 anyway. > And only one or two people reported the "justification bug" through > LikeBack. So people are mostly happy with the current behaviour. Well, when I wanted to format something, it took me lots of work, reading the source, to find a fix. Maybe this option is just used rarely, 'cause with the existing c&p code I don't see how could anyone practically use it. > > > P.S. I've added a debug window that I want to keep in the code. Just try > > to open a note for editing (my branch!) and press Ctrl+Shift+D. It works > > fine, but please raise any objections on the shortcut choice/hardcoding > > the shortcut. > > Ok. I've just done a DIFF of HEAD and your branch. > Was quite easy and to do and easy to find! > I join you the DIFF it generated. > I will look at it now: if it is not complete or erroneous please tell me. As far as I am concerned, the implementation is complete (except for the shortcut probably). However, please note two things: 1. the diff is missing the changes in focusedwidgets.h 2. there are some other changes that crept along: my c&p experiments on lines 82-90, 129-145 in the new version, which are definitely not ready for trunk. Must be more organized next time, probably making one change per branch (this is my first serious SVN experience, I used CVS before). |
From: <sl...@li...> - 2006-09-03 21:43:12
|
> But there is the question of DebugWindow... do you really need it? No, not really. > > Or is it possible to assign a number/priority/tag to our statements, and > > filter the outputted lines depending on those "tags"? > > Like do not show load/save messages, but show others. > > And when we touch something in the loading/saving code, only have to > > change one option to see them again. > > Must check... OK, I'll put that on to my TODO. If that's OK, yes, you can do that. In HEAD. > > Or perhapse it's time to drop the loading/saving messages... > > It's now mature enough. > > Indeed :) > > I understand correctly that I'm going to receive tons of replies from you > right now? Well, I'm tired, going to sleep (dead tired...), but if you do > answer, I may be able to finish and commit a couple of things tomorrow :) I'm afraid I've been really unproductive this week. Today, I've mainly looked at different shop websites in order to buy a new computer very soon. I finally found an interesting computer: I will pehapse have it this week or weekend. FINALLY, hard drive space will not be a problem (I'm always running at 100 or 0 Mo free, so I must spend time to move/remove data), the NVidia driver will work, and everything will be accelerated (currently the computer is so slow because of no graphics driver), etc. So at the end of the week, don't expect me to be very active: I will switch all my data to the new computer, reinstall everything, etc. I will reply to some mails today, because I said I will do so. I will be more deep in replied tomorrow, I promise THISE TIME. |
From: <sl...@li...> - 2006-09-03 21:37:04
|
Grrr. I configured KMail so that all Basket-devel goes in one folder, and configu= red=20 that folder to be recognized by KMail as the basket-devel mailinglist. Theorically, when replying to a message of the mailinglist, it should but t= h=20 emailinglist address in the "To" field, as it does for every other mailing= =20 lists. But not for basket-devel mailing list. Any idea why? Is anybody using KMail with that configuration and it works (or not)? Anyway, I sent the reply to Alex, and he replyed on my mail. I forward his reply for the whole mailinglist: =2D--------- Message transmis ---------- Subject: Re: [Basket-devel] How about moving all the printouts done from=20 within Basket to kdbgstream? Date: Dimanche 3 Septembre 2006 23:25 =46rom: Alex Gontmakher <gs...@cs...> To: S=E9bastien Lao=FBt <sl...@li...> On Monday 04 September 2006 00:18, you wrote: > What is kdbgstream? > The kdDebug()/kdError() functions? Yep. > I was not aware of its existence while first developing BasKet Note Pads, > so I continued with the existing codebase without having to change all the > code to the new system. Well, it's easy - just grep for all "cout" and "cerr", and remove or replace them. I can do most of it. But there is the question of DebugWindow... do y= ou really need it? > One concern I have with kdDebug/... is that it will generate too much noi= se > while developing: all "Loading"/"Saving" messages will be print out with > our own debugging lines, so it will be harder to see our debug statements. But the whole point is that it should be configurable. > Or is it possible to assign a number/priority/tag to our statements, and > filter the outputted lines depending on those "tags"? > Like do not show load/save messages, but show others. > And when we touch something in the loading/saving code, only have to chan= ge > one option to see them again. Must check... OK, I'll put that on to my TODO. > Or perhapse it's time to drop the loading/saving messages... > It's now mature enough. Indeed :) I understand correctly that I'm going to receive tons of replies from you right now? Well, I'm tired, going to sleep (dead tired...), but if you do answer, I may be able to finish and commit a couple of things tomorrow :) =2D------------------------------------------------------ =2D-=20 Best regards, S=E9bastien Lao=FBt. |
From: <sl...@li...> - 2006-09-03 21:27:18
|
What is kdbgstream? The kdDebug()/kdError() functions? I was not aware of its existence while first developing BasKet Note Pads, so I continued with the existing codebase without having to change all the code to the new system. One concern I have with kdDebug/... is that it will generate too much noise while developing: all "Loading"/"Saving" messages will be print out with our own debugging lines, so it will be harder to see our debug statements. Or is it possible to assign a number/priority/tag to our statements, and filter the outputted lines depending on those "tags"? Like do not show load/save messages, but show others. And when we touch something in the loading/saving code, only have to change one option to see them again. Or perhapse it's time to drop the loading/saving messages... It's now mature enough. |