[Home] [Downloads] [Search] [Help/forum]

Gammon Forum

See www.mushclient.com/spam for dealing with forum spam. Please read the MUSHclient FAQ!

[Folder]  Entire forum
-> [Folder]  MUSHclient
. -> [Folder]  Suggestions
. . -> [Subject]  AttachImageToLine()
Home  |  Users  |  Search  |  FAQ
Username:
Register forum user name
Password:
Forgotten password?

AttachImageToLine()

It is now over 60 days since the last post. This thread is closed.     [Refresh] Refresh page


Posted by Worstje   Netherlands  (899 posts)  [Biography] bio
Date Sat 13 Jun 2009 08:20 PM (UTC)
Message
Well, I was working on a plugin, and I thought of something that would be really nice as an addendum to everything we already have: a method to attach images to lines with a certain offset so they can enrich the text in-context rather than to be a fixed part on the screen.

I figured the images from a certain miniwindow could be used, or perhaps a specialized miniwindow could be made to hold the images for this feature.

I propose the following:

AttachImageToLine(line, imageid, xpos, ydelta, flags)

-line: number of line to attach to, or -1 for the line Tell() would be writing to next.
-imageid: image id of previously loaded image with WindowLoadImage.
-xpos:position of left edge image, relative to the left-most part of drawing area. PIXELS.
-ydelta:delta from top edge of the line the function applies to in regards to the top edge of the image.
-flags:bitwise orred field like the ones in WindowCreate etc. It should support the following flags:

*above (like the opposite of the underneath window style, not specified means it is drawn UNDERNEATH any text, which is preferable as it would not interfere with the user selecting text because of scripting oversight.)
*transparent (you figure it out)
*matches_line_visibility (only drawn when the actual line it belongs to is visible as well; default would be to draw whenever it could logically be seen.)
*no_clip (don't clip to textrectangle boundaries - could give some nice effects with wide images I reckon)

Multiple images should be addable to the same line, and likewise, they should be removable at a later date. Stretching is one of those things that might be useful as well.

(Maybe an AttachImage() could be used that adds to the current line so that the AttachImageToLine() variety could use an unsigned int and specialize on modifying old things.)

Now that I am done writing all that, maybe it would be better and use more already written features to make it slightly different: turn it into an AttachWindowToLine(). That way hotspot functionality could easily be implemented as well. Only pinch would be to make sure the same window could be in multiple places at once (perhaps even on the same screen).

Anyhow, example mockup at: http://qs.merseine.nu/images/sillymockup.png

Explanation of lines:
CYAN: top of the line that was just displayed or noted or whatever.
GREEN: left edge of text rectangle
RED: boundaries used image (miniwindow?).

The codethat would probably match that output would be (triggering on the TYPE LEVEL line):
AttachImageToLine(-1, "sword", 0, -15, flag.above + flag.transparent)
Note("\n\n\n\n\n\n")   -- for extra whitespace


If the way the Tell() code works wouldn't allow writing to the same line (and instead to a fresh one) it could be rewritten to the following with use of :

Note("%0")
AttachImageToLine(-1, "sword", 0, -15, flag.above + flag.transparent)
Note("\n\n\n\n\n\n")   -- for extra whitespace



This should make things possible like.. putting a parchment / letter background beneath written letters in your game, icons in your score, flavoring images etc. Where miniwindows are static and a part of the user interface, these could be a part of the content. And unlike inline images, which would require lineheight etc to be taken into account, this is more like a 'set relative position, done' kind of deal.

Thoughts?
[Go to top] top

Posted by Nick Gammon   Australia  (21,321 posts)  [Biography] bio   Forum Administrator
Date Reply #1 on Sun 14 Jun 2009 09:30 PM (UTC)
Message
It isn't clear from your example image - do you mean this call to simply determine the location of the miniwindow? (eg. where line 6823 is, is where the miniwindow is to be drawn?).

If so, this probably isn't a huge problem to do. As long as you don't expect a gap in the text.

And what is your plan for handling the memory usage if thousands of these windows are created? Since the user can scroll back, the windows can't be deleted once they scroll out of view, so if you have a 10,000 line buffer, and 10% have a picture attached to them, then that is 1,000 miniwindows floating around.

Quote:

Only pinch would be to make sure the same window could be in multiple places at once (perhaps even on the same screen).


This is where hotspots are going to be a problem. The same miniwindow won't be easily drawn more than once (well the drawing probably isn't a huge issue, but the mousedown on a hotspot might be, as you have multiple hotspots redirecting back to the same window).

- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top

Posted by Worstje   Netherlands  (899 posts)  [Biography] bio
Date Reply #2 on Mon 15 Jun 2009 07:32 AM (UTC)
Message
Well, I'd reckon the miniwindow or image would be drawn as-is. So say I attach the same object to different lines, it would re-use it. For 99% of purpose, that would be enough as the goal would be to spice things up with an image here or there.

It would mean that that one miniwindow being changed would show up retro-actively, e.g. it would change in the way it shows in past uses as well. But that is a matter easily adjusted through scripting - clone the miniwindow, make the changes, and use that from there on forth.

I don't really see the issue with hotspots to be honest. The click causes an event to be sent to the script (the callback), which already lacks a way to determine the miniwindow it belongs to. Or in other words, it is already hardcoded to belong to one miniwindow by the plugin author. It will still belong to one miniwindow - it is just that the same miniwindow can show at multiple places.

The matter with the old pictures lingering around indefinitely can also be fixed through the use of reference counting. Count per miniwindow how often a line refers to it (+1 when attached, -1 when lines are deleted, be it through clearing the buffer, passing line threshold and deleting old lines, etc) and once it reaches zero again, delete it. If a user wants to re-use the miniwindow in question after it was deleted, they can recreate it.

The 'delete once no longer used as attachment' method should not offer any problems with current miniwindows - it would be really rare to use the miniwindow for both your GUI and your intext-supplementing images.
[Go to top] top

Posted by Twisol   USA  (2,257 posts)  [Biography] bio
Date Reply #3 on Wed 19 Aug 2009 09:54 PM (UTC)

Amended on Wed 19 Aug 2009 09:56 PM (UTC) by Twisol

Message
Did anything ever come of this? I'd love to do something similar with hyperlinks, by creating a miniwindow and attaching it to a certain part the output, so when the text it sits on top of is clicked, it executes a command.

EDIT: I guess this would be more of an AttachWindowToLine, then, but it can do the same thing as originally intended if you just blit the image to the window.

'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol
[Go to top] top

Posted by Nick Gammon   Australia  (21,321 posts)  [Biography] bio   Forum Administrator
Date Reply #4 on Wed 19 Aug 2009 10:04 PM (UTC)
Message
Not yet. My mind boggles a bit with things like this.

I can see if images or windows are attached to lines, and you somehow don't get rid of them, you could have tens of thousands of miniwindows floating around.

- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top

Posted by Twisol   USA  (2,257 posts)  [Biography] bio
Date Reply #5 on Wed 19 Aug 2009 10:25 PM (UTC)

Amended on Wed 19 Aug 2009 10:30 PM (UTC) by Twisol

Message
Ideally, the miniwindow would be kept in memory with a refcount. When you attach a miniwindow to a line, the miniwindow's refcount gets incremented. When the line moves off the end of the buffer, the refcount is decremented. When the refcount hits 0, the miniwindow is deallocated.

WindowCreate would create a window and increment its refcount, and WindowDestroy would decrement its refcount (and only destroy if the refcount is 0). That way, if you don't want to reuse that window, you can create it, attach it, and destroy your reference to it. Otherwise you might not destroy it until later, and the miniwindow would remain in memory.

'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol
[Go to top] top

The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).

To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.


4,562 views.

It is now over 60 days since the last post. This thread is closed.     [Refresh] Refresh page

Go to topic:           Search the forum


[Go to top] top

Quick links: MUSHclient. MUSHclient help. Forum shortcuts. Posting templates. Lua modules. Lua documentation.

Information and images on this site are licensed under the Creative Commons Attribution 3.0 Australia License unless stated otherwise.

[Home]


Written by Nick Gammon - 5K   profile for Nick Gammon on Stack Exchange, a network of free, community-driven Q&A sites   Marriage equality

Comments to: Gammon Software support
[RH click to get RSS URL] Forum RSS feed ( https://gammon.com.au/rss/forum.xml )

[Best viewed with any browser - 2K]    [Hosted at FutureQuest]