Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

sir_lichtkind (5541)

sir_lichtkind
  (email not shown publicly)
http://kephra.sourceforge.net/

(brave) Perl monk from Eastern Germany
Sunday December 20, 2009
11:55 AM

features to all

caring about details - part eight

This part is especially for users of Kommodo, padre, np++, SciTe and so on. because they benefited from Kephra too. They all use the scintilla lexer written by the malaysian kein hong man++. Perl people should at least heard this name once. I filed several bugreports, he later worked on so that that the perl lexer works also in some more weird cornercases like e.g. hash keys that begin with "-". the last thing i filed was last week. it was about hierarchical folding of POD where =head1 should be parent node of =head2 and so on.

But I also found a lot bugs in WxPerl and filed things too on the WxWidgets side. My fist patches/suggestions for another Module I did for our primary config parser Config::General. And even in the Modul Clone which version numbering hack triggered some bad side effects. I even filed once a supposed bug in YAML::Tiny, but it turned out that the feature I was relying on, was an convenience feature of the YAML module which adam will not let into Y::T.
Thursday December 17, 2009
03:31 PM

bragging with none-features

caring about details - part seven.

in previous parts, I often wrote about features, that are so small, that they appear only in the changefile of smaller releases. This time, its about things you hardly ever read in about in release notes. Nonetheless they play a big part in the experience, using that program. I have to apologize, because user experience is another overused marketing term, but it decribes what I mean very well so don't mind the hype.

Let's start with icons. Because most GUI elements are common, individually crafted icons really give your app a face. Friendly, unobtrusive, understanable, distinguishable icons that integrate well with all operating systems the app can run under, bring much more joy to using your app. Our designer Jens Neuwerk has an eye on all these things and helped Kephra greatly from the earliest releases on. Now that Kephra gets more complex and the number of icons rises, we like to indicate with certain shapes and colors certain meanings, to get an even clearer communication with the use.

Another alleged none-feature is the main menu. We see it as an thematically sorted overview of nearly all functions. So you can find something needed fast. Therefore we refactor it frequently. We also add to each menu item a short help text, that appears in the statusbar while this menu item is highlighted. Many of this tooltips are obvious but new user have comfortable way of learning and it might even save for the advenced user a search in the documentation. Frankly I don't understand why not any of my other installed editors provides that too. Allright padre is here an exception too, but only few menu item hat actually a tooltip and much less were translated.

I think I once saw a tshirt with the text: "every feature i can't turn off is a bug." Humor lives from exaggeration but a switch to turn off a feature is an often underestimated feature which very seldom pops up in advertising. Not getting into your way can also have graphical expression, like in a semi transparent search dialog, that never can hide what you're looking for.

It is also not the amount of feature you have, but how well crafted and and fine tuned there are. The ~300 Perl coreops do more then the 3000+ in PHP. It can be a virtue to have less feature in an app too, because it says nothing about the service it provides to the user. Kephra 0.4.1 introduced folding, 0.4.2 enriched and finetuned it and with 0.4.3 we will change there again something. sibling fold will be replaced by a more useful level fold. How we do with less folding ops more, I already written here previously.

Consistency of the whole UI and op-behaviour is also such a "none-feature". That means also that we change something when we absolutely have to. Its also the advantage of the long developement cycle, that feature can mature. even if the testversion 0.4.4, which will introduce the plugin API will change the folding again. The normal user that might switch from stable release 0.4. to 0.5 will find a new but mature feature that most propably don't have to change in the next time.

thank you for reading
Sunday December 13, 2009
12:03 PM

Why use Kephra part 2

last time I used this topic, it was just about the line editing commands. of cource there is more. and the major idea is to pay attention to what you need right now, while you trying to achieve something another way that you do in your imagination. Its the Perl principles, brought into the realm of coding.

One of the first things we did extra to the basic edit functions was an idea of manuel. He brought this up, even before the perl workshop in dresden and I called it, lacking a better term, braceindent. You may know autoindent which let you start after pressing enter with a new line the has same indentation like the last one had. Kephra has that too but if you press enter after an open curly bracket ({), your next line is indented one tab or several spaces more (depends on your settings for that document). It also creates the matching brace below you cursor, already correctly indented. But many may not like that, so this partial behaviour is also optional.

Of course Kephra highlights matching brace, but you can also navigate through matching braces with very easy key combination, just alt+cursor not that crypting things you may found elsewhere. I did this because braces reflect the logical structure (blocks) of code and if you can easy navigate them you may easier get to the position in code you looking for than with a search. Folding commands which also mainly ease navigation and orientation in code lay on key commands that are very similar to allow fast navigation. Sometimes you want to select easily also whats inside a block/braces or string. Vim reminded me on that and one of the next Kephra versions (0.4.4) should bring that too.

0.4.3 is just too close. most features are written and im currently just cleaning the cage.
Friday December 11, 2009
04:44 PM

what are configs?

In the last post I mentioned Kephra's menu definition files. These can only work, because we have a very important file namend commandlist. There is a binding of a chunk of data to each call. the internal call, a callback that says me which state this call has or if should be disabled. also events the will be triggered if that data or status changes, an association to an icon file and the key binding is also defined there. the label and hint texts are of course part of the localisation.

how to call such files? I put it under "config/interface/*" and "config/localisation" but i'm not shure if its the right term for that. there is also a config file, where all the setiings are saved, under "config/global". Just recently i throw some parts out that are not really settings. for instance the previously used search terms and bookmark position. I put it into the search_data.yml to clean things a bit up. Also the config validate routines have now a much easier job. also the list of closed files i move from the settings into an own file. it will be a regular Kephra file session file, that holds all properties so if you restore any file from the closed files menu, you have all you settings with the marked postitions back.

There is also an extra file for the notepad content. we have a file with the templates you can insert form the templates menu. and then you have the directory "config/syntaxstyles" where are the color definitions for the syntax hightlighters are lying. there is also an dir "syntaxmodes" because we soon do a transition from these syntaxstyles to a richer format that contain more information about that language. how to comment, which interpreter /compiler to use and so on.

the we have also some files we try to hide a bit from the use in some deeper nested directories. that are subconfigs that define the help menu for a particula language or some precompiled yaml informations, that help to speed up the boot time. for instance if you translate Kephra into spanish or russian (hint, hint!) and translate the config/localisation/english.conf into an spanish.conf and put it into the localisation folder. Kephra recognises during the next start that there is a new l18n file and recompiles the language selection menu and replaces the old definition in the "config/interface/cache" folder. The label and hints for that menu item will be taken out of the meta head of the l18n file.

but all that will grow and grow and soon (before kephra 0.5) we get plugins that have to be stored somewhere with their own config files that have to be also stored somewhere. so i currently just rethinking this whole system. We had 3 extensions so far, but they all went into the core, because the're small. I don't believe that making a plugin out of every tiny thing, that is not needed to boot an app is such a smart idea like purely rational people like me to believe. I'm here very anti eclipse (the nether Khephra is a sun bearer not a sun eclipser) but Kephra is anti eclipse in all means. But thats an topic of its own, for a new article.
Wednesday December 09, 2009
08:47 PM

i like context menus

part four.

Kephra has a main menu, that is compiled from a yaml file you can open via the "config > interface" menu. So you can change it easily with the previously listed line edit commands. It serves as an overview, sorted by topic. Optimized for finding a function you looking for, not optimized for finding it after the first click, that's the task for context menus. This main menu I refactor from time to time, to keep it structure sense-making, balanced and beautiful.

On the other hand Kephra also has context menus, that are also compiled from yaml (easy changeable), but contain a selection of important commands, associated with this spot in the app. this is almost self evident and widely used in GUI software, but editors miss here large opportunities. Lets take for instance Gvim. true its not a GUI Editor of the first order, but believe me, most IDE don't do much better. GVim has only one context menu with undo, insert and some selecting commands. if you have already selected, the usual 4 edit commands will be added.

Nearly same thing with scite, padre or notepad++. Only notepads menu is extralarge because its polluted withe a shiny but fancy feature for highlighting selections of text with different colors. I currently can't do that because Wxwidgets wraps an 2 years old version of scintilla. but back to context menu. The Kommodo IDE has also an extra long context menu that you have to scroll with tiny menu buttons.

But how does it Kephra? We put also a lot of stuff into the context menu, but copied a very reasonable idea from firefox that anybody else don't seems to notice. Noone of the here named editors and most of the others don't do it, even if its the natural thing to do: don't pollute precious context menu space with calls that don't provide a useful function in this context. or lets put it more clearly: separate this menu into two. one general menu with functions about this current file (undo,redo|insert, select all|back to last edit,search dialog|save,open|close). another menu will popup if you rightclick and you selected some text. then you get a menu of actions you can do with that selected text like:copy, insert, replace, cut, delete|take as search term, take as replace term, put it into notepad,lc,uc). maybe the comment function we should put here too like padre does.

That was nice and menus don't get too long. But it doesn't stop there. if you rightclick on the margin, you get another menu with items that have to do what the margins are about. markers, bookmarks, folding and switching the visibilities of the editpanel margins. I mean its the most natural thing to do: i don't like this so i click on it and say it should go instead of searching the call in the main menu, even all these calls are just in the "view" menu. The searchbar has a context menu where you can set all the search option like in the search and replace dialog. It can also be found in main menu under "search > options". and many status bar cells have a context menu too. its a bit like kommodo does it, but only richer. in kommodo cells that react on left click have an small updown arrow that signal: here can you popup a menu by left click. In kephra left and right click do something different. i mean with left you do point an click or switch buttons. thats what leftclick also do in kephra status cells. the switch between the 2 (in one case 3) most common settings for that document property. but if you rightclick you get an context menu with a lot of more stuff associated with that property. to me its often a way to get my stuff done fast.

To sum this up: this series of articles is not about bashing other editor, but to showing why I started Kephra in the first place. because most editors do the usual stuff like all the other do it too. to innovate is one of the most misused words by microsoft but innovation is needed in a lot of places and frankly i can't change all the bits in kommodo or notepad++ i would like. beside notepad is windows only and kommodo is not free as i can get really hands on the UI design. So there is a real need for Kephra. many are happy with the things there used too but but some who are picky about details and wand to tweak even small issues by changing the configs, may find kephra fitting.

uh, one thing i forgot. there was one menu more, that is currently disabled, because the AUI::Notebook can't react on mouse events. so it maybe will appear as a regular menu in the main documents menu. Its about a list of all open docs in a way you can look up their full file path. many editors waste a full menu on that but frankly i use that never and beside that most uses are already covered by the automatically generated menu on the AUI::Notebook.
Monday December 07, 2009
04:03 PM

bookmarks and marker in editing (programming)

(or caring about details part three)

Kephra 0.4.3 will come soon and the beside the finally arriving utf support it will also have markers. its the same thing notepad++, kommodo and scite call bookmarks. Not that I want to be different, but its not the same thing as the bookmarks Kephra has for nearly 2 years and I also believe that these terms are more correct.

Nowadays that browser often set the standard, what UI means, a bookmark is a link to specific location, which marker's aren't. You make marks in your rifle or book and go just from one to the next to search the places you previously highlighted. Thats what Kephra marker do. Only with nicer icons and more TIMTOWTDI in the UI. Of course you have the known key binding, but you can also use them by mouse directly (toggle with left click on the marker margin) or by context menu (right click on the marker margin) or navigate them with icons in the searchbar.

The Kephra bookmarks have numbers and you press the key (ctrl+number) to jump directly to that spot. A fast way to navigate, if you have to switch between 2 or more places often. Marker highlight more places of interest that can also be set by search functions or an debugger. And marker can be saved in session files and file history. So if you open a file again all your marks are still there, but the bookmarks turned into marker because there could be a conflict. Every bookmark has an uniquely given number.

Nontheless: after a restart of the app all the bookmarks and marker will still be there. I even found a way to set and delete bookmarks by mouse (middle click on marker margin). Present bookmarks will deleted or the free bookmark with the lowest number will be set. because bookmarks got new nice white icons with its number in it you can see which bookmark is on the spot.

Yes that all are not the biggest IDE features, but we tend to make one well thought out and complete before we move on. And Kephra 0.4.4 will be about something completely different.
Friday December 04, 2009
08:38 AM

Why do you use Kephra?

My brother asked me recently this question, because after his quick view over the net pages it seemed to lack great, shiny and distinctive features. He never used Perl but this question is also relevant to many programmer here, because Padre promises some big features Kephra don't seems to have on it's list and Eclipse and Netbeans (what he uses beside Notepad++) seem to play in another class.

First of all Kephra is very stable (we achieved to close the last known bug/issue last week) and in itself complete, which I consider a feature. Las week I read that eclipse has issues(clear bugs) that weren't fixed in 6 years, with no hope for the future.

My positive reason to use Kephra: I'm very fast with it. I'm used to a lot of function that I even could not tell if asked so the precise answer to my brothers question came to me days later.

For instance in regular formated code there is one command in one line. And when you rewriting code you move lines and delete lines, copy lines. That are all things that I do within Kephra directly. <Ctrl> + <Alt> + <Cursor> moves the current line (like in open office, but they choose this key binding independently). <Ctrl> + <Shift> + <C> copy the line, <Ctrl> + <Alt> + <L> and <Ctrl> + <Alt> + <RL> chops the left or right part of the line (devided by the text cursor (caret)).<Ctrl> + <Shift> + <Del> deletes the current line. this all are smaller things, misplaced in buzzword ejakulations, but to me its important. Beside that there are some larger features in the queue.

P.S. Yesterday i fixed the line move feature a bit. The curser moved always to the begin of the line, not anymore. And the notepad, that shows the first signes to slowly morphing into emacs-orgmode (which i admire and want to have in kephra ASAP), hast this feature now too. I use this often as todo list, where easy moving lines by priority is good to have.
Saturday November 28, 2009
09:47 AM

User is (should be) King

In recent Kephra refactorings, I changed a behaviour of the autoconverter. It works now a bit differently then in common editors, but it is not a big thing. The mindset behind it I find important. It's also very satisfying to see it working in Kephra 0.4.2.9 the way i feel is right.

The topic is EOL, which is the 3 letter acronym for the end of line character, the things you usually name in perl "\r\n". And what is an autoconverter? That is an algorithm that changes a file content while loading it into the editor, before you can touch the text. Don't worry, it will be done only in case you request it by changing the default settings for opened files (file > defaultsettings > open). Sometimes its what you want and I believe in freedom.

However I prefer to notice it, when my editor changes something without asking. I prefer it also to redo this kind of change easily. but please no popups or special widgets or visual noise of any kind.

The solution I found was embarrassingly simple. after loading the file I reset the undo history and make the formater after it, followed by a save call. You will notice that a formater did something, because the redo button has color. normally the button is disabled when you open a file. and if you like, just push the redo button. I love it.

There are many details more ...
Wednesday November 25, 2009
04:11 PM

releasing on sourceforge

while releasing Kephra 0.4.2 on sourceforge, I noticed that the changed their system completely. Its now much simpler to use, but 3 tricks there are still. Better you know them in forehand.

Step 1: mark the folder you want to put your uploaded files into, by right click, open the context menu and select the second item: "upload here". if you don't do that the file will appear at the bottom of the filetree.

Step 2: upload a/the textfile, containing the release notes. after its uploaded and appears in the tree, select the file and check the box "release note" on the right margin. These will be exactly the release notes as before, that appear when clicking on the scribe icon behind a file.

Step 3: upload you files. then select them one after the other and give them in the same box on the right margin labels and select the fitting release note from the dropdown menu. Save this settings and do not select the platform this file is intended for, unless you want to be this file the default download for the entire project when a user uses this OS around his browser, surfing on sourceforge.net.

Nice Bonus: MDA5 and SHA1 digest are generated automatically.
Friday November 20, 2009
05:32 PM

0.4.2.1 after the long 0.4.2

The release of Kephra 0.4.2 thought me lot of things. Yes it was inevitable that after a long complicated internal rewrite, a lot of nifty bugs poped up all over the place. It took nearly 3 days to get a devent version for a rerelease.

It demonstrated also that my roadmap was to static and that the steps are to big. 0.4.3 will come much sooner and concentrate on only one issue: codings.

0.4.2.1 shows the first signs of that: a statusbar field to display the current coding. I used this opportunity to create the status bar from a config file and sync the position of context menus that change some values, displayed in the statusbar, with its status bar field. Thast was a lot for just one day.