When one creates a new toplevel or button in TK, one needs to enter a pathname.
I have seen a basic code which looks like:
toplevel .a
...
button .a.b ...
My question is:
Are the dots treated differently than letters? Are they some sort of hierarchy delimiters, which create parent child relationship? I have looked at wiki TK and failed to find an answer to that.
Many thanks,
-Lior
As other answers have said, dots are used to represent a hierarchy, just as / or \ is used to represent a filesystem hierarchy.
Placing widgets in a hierarchy is not, strictly speaking, necessary. One advantage in doing so is that geometry managers such as grid and pack default to managing children in their parents. For example 'pack .a.b.c' will pack the widget a.b.c within the widget .a.b. This makes it easy to do simple layouts.
The same effect in many cases can be achieved by telling grid and pack into which container a child should be placed. Foe example, 'pack .c -in .a.b' will put the widget .c in the container .a.b. This let's you keep your hierarchy shallow, and makes refactoring a little easier.
See http://www.beedub.com/book/2nd/TKINTRO.doc.html for a good introduction to tk fundamentals.
Yes, they are! They separate for instance a frame with the content that are widgets:
set f [frame .hello]
button $f.b -text "Hello button"
pack $f.b
pack $f
As you can see in this example, the f is evaluated as variable, not f.b
You can also write pack ${f}.b but this is not needed as the dot is seen not to be part of the variable.
Yes - it's for the hierarchy. Have a look at TkDocs on the subject:
The frame, which was a child of the root, was named ".c". We could have put pretty much anything in place of the "c", naming it for example ".content". This name is purely for use by your program, so it's best to choose something meaningful. The controls that were children of the frame were given names like ".c.feet", ".c.meters", ".c.flbl", and so on. If there were any widgets at a deeper level of the hierarchy, we'd add another "." and then a unique identifier.
Related
Is it possible to comment out specific classes inside the HTML (<div class="" ...>)?
For example:
<div data-group="group1" data-container="true" class="container-lg d-flex /* slider */ p-0">
Where in this example the class "slider" should be (temporarily) excluded from the class list.
[UPDATE]
Based on the comments I understand the way of thinking, so I go for the solution Lee Taylor mentioned. When I want to disable a specific class assignment, I just add a prefix to that class. For example:
<div class="slider container"...
becomes:
<div class="disable-slider container"...
Life could be so easy if the mind is thinking too complex :-D
Thank you all for thinking with me!
[/UPDATE]
This would make life a lot easier, in my opinion, in these ways:
You don't have to switch to your style sheet and go searching for the matching class, commenting out and switch back again to the code.
It's clear for everyone that you just exclude the complete function, which - if named clearly - gives other developers a better overview.
For testing purposes you could use this as (style) modules, which are enabled/disabled in a snap! Again, no more hopping between screens/tabs/windows.
Easier debugging. Just comment out some classes and you've got the source of the problem in no time.
It stimulates developers to use recognizable and clearly named classes
Currently I copy the whole element/row, comment this out and add a comment and then paste the copied row below. Then I remove classes from this line of code.
Most of the time this doesn't get updated, so you can't see it as a reliable backup if you're debugging.
I know for sure that such would be possible with JS, but why? (Also changing the HTML structure with JS gives a lot of headaches when it comes to layout shifts and not everyone has the possibility to make use of server side scripting.) Such should exist HTML in my opinion.
Am I the only one who has this in mind?
Per the HTML Specification on the class attribute:
When specified on HTML elements, the class attribute must have a value that is a set of space-separated tokens representing the various classes that the element belongs to.
Here is the definition for space-separated tokens:
A set of space-separated tokens is a string containing zero or more words (known as tokens) separated by one or more ASCII whitespace, where words consist of any string of one or more characters, none of which are ASCII whitespace.
A string containing a set of space-separated tokens may have leading or trailing ASCII whitespace.
Therefore, no, you should technically not be allowed to comment out class list members in any way. If any implementation of the specification does allow this, then it is undefined behavior and should not be depended upon.
Dearest StackOverflow homies,
I'm playing with HTML that was output by EverNote and need to parse the following:
Note Title
Note anchor (hyperlink identities of the notes themselves)
Note Creation Date
Note Content, and
Intra-notebook hyperlinks (the
links within the content of a note to another note's anchor)
According to examples by Duncan Temple Lang, author of the [r] XML package and a SO answer by #jdharrison, I have been able to parse the Note Title, Note anchor, and Note Creation Dates with relative ease. For those who may be interested, the commands to do so are
require("XML")
rawHTML <- paste(readLines("EverNotebook.html"), collapse="\n") #Yes... this is noob code
doc = htmlTreeParse(rawHTML,useInternalNodes=T)
#Get Note Titles
html.titles<-xpathApply(doc, "//h1", xmlValue)
#Get Note Title Anchors
html.tAnchors<-xpathApply(doc, "//a[#name]", xmlGetAttr, "name")
#Get Note Creation Date
html.Dates<-xpathApply(doc, "//table[#bgcolor]/tr/td/i", xmlValue)
Here's a fiddle of an example HTML EverNote export.
I'm stuck on parsing 1. Note Contents and 2. Intra-notebook hyperlinks.
Taking a closer look at the code it is apparent the solution for the first part is to return every upper-most* div that does NOT include a table with attribute bgcolor="#D4DDE5." How is this accomplished?
Duncan says that it is possible to use XPath to parse XML according to NOT conditions:
"It allows us to express things such as "find me all nodes named a" or "find me all nodes named a that have no attribute named b" or "nodes a that >have an attribute b equal to 'bob'" or "find me all nodes a which have c as >an ancestor node"
However he does not go on to describe how the XML package can parse exclusions... so I'm stuck there.
Addressing the second part, consider the format of anchors to other notes in the same notebook:
<a href="#13178">
The goal with these is to procure their number and yet this is difficult because they are solely distinguished from www links by the # prefix. Information on how to parse for these particular anchors via partial matching of their value (in this case #) is sparse - maybe even requiring grep(). How can one use the XML package to parse for these special hrefs? I describe both problems here since it's possible a solution to the first part may aid the second... but perhaps I'm wrong. Any advice?
UPDATE 1
By upper-most div I intend to say outer-most div. The contents of every note in an EverNote HMTL export are within the DOMs outer-most divs. Thus the interest is to return every outer-most div that does NOT include a table with attribute bgcolor="#D4DDE5."
"....to return every upper-most div that does NOT include a table with attribute bgcolor="#D4DDE5." How is this accomplished?"
One possible way ignoring 'upper-most' as I don't know exactly how would you define it :
//div[not(table[#bgcolor='#D4DDE5'])]
Above XPath reads: select all <div> not having child element <table> with bgcolor attribute equals #D4DDE5.
I'm not sure about what you mean by "parse" in the 2nd part of the question. If you simply want to get all of those links having special href, you can partially match the href attribute using starts-with() or contains() :
//a[starts-with(#href, '#')]
//a[contains(#href, '#')]
UPDATE :
Taking "outer-most" div into consideration :
//div[not(table[#bgcolor='#D4DDE5']) and not(ancestor::div)]
Side note : I don't know exactly how XPath not() is defined, but if it works like negation in general, (this worked as confirmed by OP in the comment below) you can apply one of De Morgan's law :
"not (A or B)" is the same as "(not A) and (not B)".
so that the updated XPath can be slightly simplified to :
//div[not(table[#bgcolor='#D4DDE5'] or ancestor::div)]
I am running Org-mode 8.2.6 in Emacs 24.3.1 on Windows 7 Ultimate and have encountered a peculiarity with how links work in HTML exported from Org-mode. I have used org-id extensively to assign unique IDs to headings in Org-mode files (stored in the :PROPERTIES: drawer of the heading).
Before the new exporter framework was introduced in Org-mode 8.0 all of these links worked without issue. No matter the level of the heading's hierarchy, exported-HTML ID-based links worked fine. However, using the new exporter framework produces different results. Now, ID-based links always fail when the target heading lies at a level below the headline level defined in the export settings, which defaults to level 3 (H:3). Note: This is true only for the exported HTML; ID-based links work perfectly within Emacs.
Here is a minimal example that demonstrates this behavior when I export it to HTML (see annotations for details):
* Headline Level 1
** Headline Level 2
*** Headline Level 3
:PROPERTIES:
:ID: 307db49e-e001-4a7b-9541-96eee2ae6f06
:END:
**** <<heading-level-4>>Non-headline level
:PROPERTIES:
:ID: 3be9179d-f838-4052-93ca-6c76c9aff12d
:END:
** Headline Level 2
*** Headline Level 3
Now I want to link to information that appears elsewhere in the file. Links work as
expected within Emacs. When exported to HTML, however, links do not work as they
did before the new exporter framework was introduced in Org-mode 8.0.
**** ID-based link: [[id:307db49e-e001-4a7b-9541-96eee2ae6f06][Headline Level 3]]
This link /does/ work. Using IDs always works for links to any headline level. By
"headline level" I mean any Org-mode heading that is defined as a headline
(default H:3).
**** ID-based link: [[id:3be9179d-f838-4052-93ca-6c76c9aff12d][Non-headline level]]
This link using the ID /doesn't/ work when exported to HTML using the new exporter
framework. Now, using IDs as the target for links /always/ fails for links to any
headline lower than the headline level defined in the export settings.
**** Non-ID-based link: [[heading-level-4][Non-headline level]]
Using an internal link works, but I have /many/ existing files that depend on IDs
for links at heading levels lower than the levels I want treated as (numbered)
headlines, and I also sometimes link to targets in other files, in which case,
using ID's creates a much simpler workflow.
If the file above is named demo-links.org the default output file is demo-links.html. The HTML for the target of the first working link looks like this:
<h4 id="sec-1-1-1"><a id="ID-307db49e-e001-4a7b-9541-96eee2ae6f06" name="ID-307db49e-e001-4a7b-9541-96eee2ae6f06"></a><span class="section-number-4">1.1.1</span> Headline Level 3</h4>
and the HTML for the link to it looks like this:
Headline Level 3
The link ID is part of the target code but isn't used in the linking code.
The HTML for the target of the non-working link looks like this:
<ul class="org-ul"><li><a id="heading-level-4" name="heading-level-4"></a>Non-headline level<br /><div class="outline-text-5" id="text-1-1-1-1"></div></li></ul>
Notice that the code that is generated does NOT contain the ID (3be9179d-f838-4052-93ca-6c76c9aff12d). Neither does it contain a section ID like the previous link did.
The HTML for the link to it looks like this:
Non-headline level
I believe the relevant code in ox-html.el appears following the comment "Links pointing to a headline" but I'm a novice (at best) with elisp.
My question is this: Is this behavior by design, or is there some setting I can alter that will make the export work the way it did before the new export framework was introduced?
I encounter the problem too. What's more, text enclosed between "<<" and ">>" can be showed in the exported HTML in org-7.9 while it can't be showed in org-8.2
With limited reputations, I can't vote the item up, so I just answer it without a correct answer here. (=_=)
Looking at the code of the org-html-headline function, it seems that the "standard headline" case (whatever is exported to hN) is handling the custom IDs specially:
(let* (...
(ids (remove nil
(list (org-element-property :CUSTOM_ID headline)
(concat "sec-" section-number)
(org-element-property :ID headline))))
(preferred-id (car ids)) ;; <- here, id for the header is sec-XXX
(extra-ids (cdr ids))
...)
(format ...
(format "outline-container-%s"
(or (org-element-property :CUSTOM_ID headline)
(concat "sec-" section-number)))
...
(format "\n<h%d id=\"%s\">%s%s</h%d>\n"
level1
preferred-id
(mapconcat
(lambda (x)
(let ((id (org-export-solidify-link-text
(if (org-uuidgen-p x) (concat "ID-" x)
x))))
(org-html--anchor id))) ;; <- generate a list of <a id=ID-XXX></a>
extra-ids "")
full-text
level1)
...))
That's where those <a id="ID-XXX" name="ID-XXX"></a> snippets come from (placeholder anchor, just to expose an additional ID)
Unfortunately, in the case of headlines that translate into list items, there is no such handling of ID/CUSTOM_ID, which quite frankly looks like a bug to me.
So while it is possible to rewrite org-html-headline to do the same treatment for list items, it's unfortunately not as easy as modifying a setting (and code modification would pretty fragile)
I would suggest opening a bug report, after all it seems to be a regression.
I am looking to avoid using xpaths that are 'xpath position'. Reason being, the xpath can change and fail an automation test if a new object is on the page and shifts the expected xpath position.
But on some web pages, this is the only xpath I can find. For example, I am looking to click a tab called 'FooBar'.
If I use the Selenium IDE FireFox plugin, I get:
//td[12]/a/font
If I use the FirePath Firefox plugin, I get:
html/body/form/table[2]/tbody/tr/td[12]/font
If a new tab called "Hello, World" is added to the web page (before FooBar tab) then FooBar tab will change and have an xpath position of
//td[13]/a/font
What would you suggest to do?
TY!
Instead of using absolute xpath you could use relateive xpath which is short and more reliable.
Say
<td id="FooBar" name="FooBar">FooBar</td>
By.id("FooBar");
By.name("FooBar");
By.xpath("//td[text()='FooBar']") //exact match
By.xpath("//td[#id='FooBar']") //with any attribute value
By.xpath("//td[contains(text(),'oBar')]") //partial match with contains function
By.xpath("//td[starts-with(text(),'FooB')]") //partial match with startswith function
This blog post may be useful for you.
Relative xpath is good idea. relative css is even better(faster)
If possible suggest/request id for element.
Check also chrome -> check element -> copy css/xpath
Using //td is not a good idea because it will return all your td nodes. Any predicate such as //td[25] will be a very fragile selection because any td added to any previous table will change its result. Using plugins to generate XPath is great to find quickly what you want, but its always best to use it just as a starting point, and then analyze the structure of the file to write a locator that will be harder to break when changes occur.
The best locators are anchored to invariant values or attributes. Plugins usually won't suggest id or attribute anchors. They usually use absolute positional expressions. If can rewrite your locator path in terms of invariant structures in the file, you can then select the elements or text that you want relative to it.
For example, suppose you have
<body> ...
... lots of code....
<h1>header that has a special word</h1>
... other tags and text but not `h1` ...
<table id="some-id">
...
<td>some-invariant-text</td>
<td>other text</td>
<td>the field that you want</td>
...
The table has an ID. That's the best anchor. Now you can select the table as
//table[#id='some-id']
But many times you don't have the id, or even some other invariant attribute. You can still try to discover a pattern. For example: suppose that the last <h1> before the table you want contains a word you can match, you could still find the table using:
//table[preceding::h1[1][contains(.,'word')]]
Once you have the table, you can use relative axes to find the other nodes. Let's assume you want an td but there are no attributes on any tbody, tr, etc. You can still look for some invariant text. Tables usually have headers, or some fixed text which you can match. In the example above, if you find a td that is 2 fields before the one that you want, you could use:
//table[preceding::h1[1][contains(.,'word')]]/td[preceding-sibling::td[2][.='some-invariant-text']]
This is a simple example. If you apply some of these suggestions to the file you are working on, you can improve your XPath expression and make your selection code more robust.
What is the best format to communicate an array of strings in one string to users who are not geeks?
I could do it like this:
Item1, Item2, Item3
But that becomes meaningless when the strings contain spaces and commas.
I could also do it this way:
"Item1", "Item2", "Item3"
However, I would like to avoid escaping the array elements because escaped characters can be confusing to the uninitiated.
Edit: I should have clarified that I need the formatted string to be one-line. Basically, I have a list of lists displayed in a .Net Winforms ListView (although this question is language-agnostic). I need to show the users a one-line "snapshot" of the list next to the list's name in the ListView, so they get a general idea of what the list contains.
You can pick a character like pipe (|) which are not used much outside programs. It also used in wiki markup for tables which may be intuitive to those who are familiar with wiki markup.
Item1| Item2| Item3
In a GUI or color TUI, shade each element individually. In a monochrome TUI, add a couple of spaces and advance to the next tab position (\t) between each word.
Using JSON, the above list would look like:
'["Item1", "Item2", "Item3"]'.
This is unambiguous and a syntax in widespread use. Just explain the nested syntax a little bit and they'll probably get it.
Of course, if this is to be displayed in a UI, then you don't necessarily want unambiguous syntax as much as you want it to actually look like something intended for the end user. In that case it would depend exactly how you are displaying this to the user.
Display each element as a cell in a table.
How about line breaks after each string? :>
Display each string on a separate line, with line numbers:
1. Make a list
2. Check it twice
3. Say something nice
It's the way people write lists in the real world, y'know :)
Use some kind of typographical convention, for example a bold hashmark and space between strings.
milk # eggs # bread # apples # lettuce # carrots
CSV. Because the very first thing your non-technical user is going to do with delimited data is import it into a spreadsheet.