Zencode interface stays up after action

Bug #724541 reported by Jan Bilek
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Scribes
Fix Committed
Medium
Mystilleef

Bug Description

When Zencode interface is used, "Zencode abbreviation" field should pop up after pressing Shift-Ctrl-comma, and after entering the code and pressing Enter it should disappear and focus should be returned back to editor (desired behavior designed by Zencode creator - please see http://vimeo.com/7405114).

In Scribes, even after the Zen code is entered and Enter is pressed, Zencode interface pops up again and stays in focus - you have to click to editor to continue editing.

I use 0.4.849-1, latest build available in Arch Linux - I am sorry if this has been fixed in 0.4.899.

BTW, Scribes is really cool, thank you.

Revision history for this message
Mystilleef (mystilleef) wrote :

To be honest. I've stopped working on Zen Coding just because the library is very complicated, buggy and difficult to use. I recommend Sparkup instead. I left Zen Coding in Scribes for historical reasons.

Revision history for this message
Jan Bilek (honzzz) wrote :

Oh, I see. I just really like that thing when you write a couple of words one under each other and then you wrap them in code... Sparkup does not have that feature. Thanx a lot anyway, Scribes is great, too bad Zencoding library is not that good.

Revision history for this message
Mystilleef (mystilleef) wrote :

Yes, use Zencoding when appropriate. However, I recommend Sparkup.

Changed in scribes:
status: New → Won't Fix
Revision history for this message
Jan Bilek (honzzz) wrote :

I totally understand your point of view - I don't like dealing with messy code either. It's just that from user's point of view I think Zencode has many advantages over Sparkup. It's not just about writing code but also about editing code - things like select in tag and wrap with abbreviation... I don't think Sparkup does that.

BTW, why is Sparkap in Scribes implemented always with the Sparkup bar, never writing directly inside editor? I am just curious; the workflow 'write inside editor and then hit the shortcut to unfold the code' seems more natural, one step shorter and more 'usable' then 'hit the shortcut to pop up the bar at the bottom, write inside it and then hit Enter to unfold the code inside of the editor'. Please don't take this the wrong way - I am not criticising, I am just asking.

I hope that you will at least keep Zencode in Scribes in the future. Just out of curiosity - would you be willing to accept money for fixing that bug?

Thank you for your time.

Mystilleef (mystilleef)
Changed in scribes:
status: Won't Fix → In Progress
status: In Progress → Triaged
importance: Undecided → Medium
assignee: nobody → Mystilleef (mystilleef)
Revision history for this message
Mystilleef (mystilleef) wrote :

Ooops, I misread your bug report. Sorry about that. It's been a long day. :-)

<p>ul>li*8>a+h4>p>li*10>a

If a user writes that in the buffer it's hard to figure out were the trigger starts. The cleanest solution is what I provide with Sparkup. Have the user write triggers in a separate user interface. The separate user interface also psychologically reinforces the user is about to do something special.

I'll keep Zencoding in Scribes. Open source projects are always evolving. Who knows the next release may fix all the problems I have with it.

I'll fix the bug without any monetary compensations, thanks. :-)

Revision history for this message
Jan Bilek (honzzz) wrote :

Thank you. I have an idea, but I am a web developer and I don't know too much about Gtk and desktop apps programming so I might be totally wrong.

I use XFCE and there is an editor called Gedit - I noticed that it uses the same themes (Oblivion etc.) like Scribes, it has exactly the same items in the toolbar and basically... many things are the same, so I guess that Scribes and Gedit share some common Gtk background or something? And Gedit Zencoding plugin is just awesome; Zen coding done right. Could you just somehow use the same plugin in Scribes? I have to admit that I have no idea how simple/difficult would that be... I thought maybe it would be just something like from gedit-zencoding import *. if I am wrong, I am sorry about that.

Of course you could say I can just use Gedit... but I fell in love with that original ultra-simplistic no-tabs no-menubar load-session workflow-oriented approach that Scribes does - that's what I call Zen. Ironically, I love Scribes for the same reasons I love Zen coding done right in Gedit. If by any chance you could simply fix Zencoding in Scribes by adding that Gedit Zencoding plugin into Scribes, that would be Nirvana for me :-)

Revision history for this message
Mystilleef (mystilleef) wrote :

Gedit and Scribes have different plugin APIs so that won't work. I can't think of anything the Gedit zencoding plugins could do marginally better than Scribes. Correct me if I'm wrong.

Revision history for this message
Jan Bilek (honzzz) wrote :

It was worth a shot, thank you very much anyway:-)

I don't think you are wrong, it's probably just a matter of opinion. I can only write why I like that Gedit Zencoding plugin. First off, it does not have that bug - when zen code is entered into the interface, focus goes back to editor immediately after Enter is pressed, you can continue editing without the need to grab mouse and click into editor. I also like that when you want to wrap something with abbreviation, then when you start typing the zen code in, you can instantly real-time see where the wrapper goes, how it changes the code... even before you hit enter.

You also wrote that "separate user interface also psychologically reinforces the user is about to do something special" - I don't see it that way. I feel Zen coding is something natural and easy, it should not feel special - exactly the opposite, it should feel 'invisible'.

That's one of the reasons I prefer Zencoding over Sparkup in Scribes - I think it's better when you are visually entering the code on the same spot where that code goes (easier orientation) - and that's also why I like that Gedit plugin - even when you need to use the Zencode interface (wrapping etc.), a little unobtrusive pop-up appears right next to the place where the final code will go after zen code is entered. You can keep your eyes on the edited part of the program all the time, even when using interface, you don't have to switch to the bottom of the screen and back. Although I have to say that this is much less obtrusive than the need to go from keyboard to mouse and back every time I use that Zencoding interface (because of that bug).

Generally, gedit plugin feels a little bit more easy, natural, with 'shorter' workflow - less steps to get things done.

But that's just my opinion. I just really like Zen coding in Gedit - everything else I like better in Scribes.

Revision history for this message
Mystilleef (mystilleef) wrote :

I committed a fix to the dev branch.

The __only__ advantage I see the Gedit plugin has is live
updates. When I'm motivated I'll update Sparkup and
Zencoding with live updates.

I know my opinion doesn't matter much. However, I still
recommend you use Sparkup over Zencoding. It's better
integrated into Scribes and thus provides a better experience
over Zencoding. In my experiences it's behavior is very
consistent compared to zencoding.

Zencoding may have more features, but most of them are
broken, erratic or do not work well. That's just my 2 cents.
Use whatever makes you happy.

With respect to the bar, I prefer a single consistent
interface for expanding triggers. If I could get rid of the
buffer trigger mechanism in Zencoding and use the bar
approach only, I would. That would make things so much
cleaner.

I don't believe using the bars disrupts workflow at all.
Particularly because coming up with Zencoding or Sparkup
triggers is cognitively tasking and a workflow disruptor
itself. I know because I've watched lots of screencasts and
I've seen how cognitively tasking and disruptive creating
Zencoding triggers are. The fact is you're going to break
your workflow the moment you start creating a zencoding
trigger. So I doubt spending less than half a second to
show the bar is a workflow deal breaker. Especially when
you're going to spend the next couples of seconds struggling
to create a Zencoding trigger. This why I think the bar is
important. It puts you in a different space for writing
zencoding triggers.

Revision history for this message
Jan Bilek (honzzz) wrote :

About that bar... now that I think about it, I guess you might be right. Maybe it's just that I am used to zencode inside editor - but I would have no problem getting used to the bar and I never thought that bar were a workflow deal breaker.

I really only wanted to report that bug... and about that Gedit plugin, it was just my $0.02, it was never my intention to teach you about workflow or something - seeing how well thought out Scribes is, you really know your stuff.

Revision history for this message
Mystilleef (mystilleef) wrote :

Scribes is well thought out because of its community. It's
because of people, like you, who appreciate the project
enough to contribute and report bugs.

You could easily have said, "Screw this I'll just keep using
Gedit, or another text editor." Instead you reported a bug.
You pointed a new feature. And you even reignited my
interest in Zencoding again.

Now because of you, Scribes is going to have live updates
and one less bug. I'm sure if you could implement them
yourself you would. So how can I take credit for this?

This is just one example. Multiply this example by hundreds
of similar situations and you'll immediately see that
Scribes evolves through the community.

The fact is I can't compete with the brain power of the
community. I'm not __always__ right. It's okay to tell me
I'm wrong and you disagree with me vehemently. I might come
to the see the light 6 months down the road. It's happened
before, a lot.

Changed in scribes:
status: Triaged → Fix Committed
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.